NTP-DRMT：測試行動設備中OMA數位使用權管理功能的符合性與互通性之測試工具

全文

(1)國立交通大學資訊學院資訊科技（IT）產業研發碩士班碩士論文. NTP-DRMT：測試行動設備中 OMA 數位使用權管理功能的符合性與互通性之測試工具 NTP-DRMT：A Conformance and Interoperability Test Tool for OMA Digital Rights Management of Mobile Devices. 研究生：黃亭愷指導教授：林一平. 教授. 陳懷恩. 教授. 中華民國九十七年七月.

(2) NTP-DRMT：測試行動設備中 OMA 數位使用權管理功能的符合性與互通性之測試工具 NTP-DRMT：A Conformance and Interoperability Test Tool for OMA Digital Rights Management of Mobile Devices. 研究生：黃亭愷. Student：Ting-Kai Huang. 指導教授：林一平. Advisor：Yi-Bing Lin. 陳懷恩. Whai-En Chen. 國立交通大學資訊學院資訊科技（IT）產業研發碩士班碩士論文. A Thesis Submitted to College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Master in. Industrial Technology R & D Master Program on Computer Science and Engineering. July 2008. Hsinchu, Taiwan, Republic of China. 中華民國九十七年七月.

(3) NTP-DRMT：測試行動設備中 OMA 數位使用權管理功能的符合性與互通性之測試工具. 學生：黃亭愷. 指導教授：林一平陳懷恩. 國立交通大學資訊學院產業研發碩士班. 中文摘要本論文開發一個數位使用權管理(Digital Rights Management)的符合性與互通性之測試工具，測試待測物(如:手機)是否符合開放行動通訊聯盟(Open Mobile Alliance)的服務互通性測試之標準。數位使用權管理是一種防護(或保護)的機制，發行者利用使用權來管理被使用者取得的多媒體資料。使用者必須依照使用權物件(Rights Objects)的規則來存取被數位使用權所保護的文件(DRM Content)。當行動數位裝置使用 DRM 的應用服務之前，我們必須測試此 DRM 應用服務的開發是正確的依照 OMA 所訂定的規格。我們將展示在 Testing and Test Control Notation version 3 (TTCN-3)下如何有效率的開發 DRM 的測試例子。. i.

(4) NTP-DRMT：A Conformance and Interoperability Test Tool for OMA Digital Rights Management of Mobile Devices. student：Ting-Kai Huang. Advisors：Dr. Yi-Bing Lin Dr. Whai-En Chen. Industrial Technology R & D Master Program of Computer Science College National Chiao Tung University. Abstract. This thesis describes a conformance and interoperability test tool for Digital Rights Management (DRM) developed on an Open Mobile Alliance (OMA) service interoperability test platform. DRM is a security (protection) mechanism that allows a content issuer to manage the media objects to be delivered to the users with copyright protection. In DRM, the users then access DRM Content (i.e., the protected media objects) according to the Rights Objects. Before a DRM application is launched for a mobile device, it is essential to conduct testing to ensure that the DRM mechanism is correctly implemented. Based on the Testing and Test Control Notation version 3 (TTCN-3) specifications, we show how DRM test cases can be efficiently implemented.. ii.

(5) Acknowledgment I would especially like to thank my advisors, Prof. Yi-Bing Lin and Prof. Whai-En Chen. Without their supervision and perspicacious advices, I cannot complete this thesis. I would also like to thank my colleagues in Laboratory 117.. I would also like to thank Chun-Chieh Wang and Pai-Tsan Huang for their help in developing NTP-DRMT.. I would also like to express my thanks to my friends. They encourage me and make me feel confidence to complete this thesie.. Finally, I want to thank my dear parents and my sister for their unfailing love and firmly support in these years.. iii.

(6) Contents. 中文摘要 ................................................................................................................ i Abstract .................................................................................................................ii Acknowledgment .................................................................................................iii Contents................................................................................................................ iv List of Figures ....................................................................................................... v Chapter 1 Introduction .......................................................................................... 1 1.1 OMA DRM............................................................................................... 1 1.2 NTP-DRMT.............................................................................................. 3 1.3 Test Procedure for the DRM Registration ............................................... 5 Chapter 2 TTCN-3 Based Test System................................................................. 7 2.1 DRM Test Management and Control (TMC)........................................... 8 2.2. DRM TTCN-3 Executable (TE)............................................................ 10 2.3. DRM SUT Adapter (SA)....................................................................... 12 Chapter 3 TTCN-3 Interfaces for DRM.............................................................. 14 3.1 The TTCN-3 Control Interface (TCI) for DRM..................................... 14 3.2. The TTCN-3 Runtime Interface (TRI) for DRM.................................. 17 Chapter 4 A DRM Conformance Test Scenario .................................................. 20 Chapter 5 Conclusions ........................................................................................ 25 Reference............................................................................................................. 26 Appendix A The conformance and interoperability test cases ........................... 28. iv.

(7) List of Figures. Figure 1. The DRM architecture. .......................................................................... 2 Figure 2. The Rights Object format. ..................................................................... 3 Figure 3. Conformance and interoperability test environment for OMA DRM. .. 4 Figure 4. The test case for DRM registration procedure....................................... 6 Figure 5. TTCN-3 based NTP-DRMT. ................................................................. 7 Figure 6. Graphical test log for DRM registration................................................ 9 Figure 7. The structure of the DRM ETS............................................................ 11 Figure 8. Interaction between the SA and the TE in NTP-DRMT. .................... 12 Figure 9. An example of DRM module parameter. ............................................ 15 Figure 10. DRM test logging example................................................................ 15 Figure 11. DRM encode operation...................................................................... 16 Figure 12. DRM decode operation...................................................................... 17 Figure 13. DRM adapter operation. .................................................................... 18 Figure 14. DRM test case “missing States in RI Hello processing” state diagram. ............................................................................................................................. 21 Figure 15. DRM test case “missing States in RI Hello processing”. ................. 22 Figure 16. The f_DRM_2_con_5_a_rcvMsg function. .............................. 24. v.

(8) Chapter 1 Introduction. 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.. 1.

(9) 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. 2.

(10) 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 3 ), it permission field only specifies the permissions without any constraint (Figure 2 ○. 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].. 3.

(11) 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 1 ). After the SUT receives the response, the tester verifies if the issued by a tester (Figure 3 ○. 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. 4.

(12) 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.. 5.

(13) 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.. 6.

(14) Chapter 2 TTCN-3 Based Test System. The test system NTP-DRMT is implemented based on TTCN-3. This system manages DRM test execution, interprets/executes compiled TTCN-3 code, and implements proper communications with the SUT. As illustrated in Figure 5, NTP-DRMT consists of the following parts.. Figure 5. TTCN-3 based NTP-DRMT.. The Test Management and Control (TMC; Figure 5 ①) is responsible for the test execution control and the test event logging. The TTCN-3 Executable (TE; Figure 5 ②) is responsible for the interpretation or the execution of the DRM modules (i.e., abstract test suites). The SUT 7.

(15) Adapter (SA; Figure 5 ③) adapts the TTCN-3 communication operations between the TE and the SUT (Figure 5 ⑤). The Platform Adapter (PA; Figure 5 ④) adapts the TE to an operating system (e.g., Microsoft Windows XP) by creating a single notion of time for NTP-DRMT and implementing the external functions as well as timers.. Two interfaces are defined inside NTP-DRMT. The TTCN-3 Control Interface (TCI; Figure 5 A ) specifies the interface between the TMC and the TE. The TTCN-3 Runtime Interface (TRI; ○ B ) defines the interface between the TE and the SA/PA. A third interface Test Figure 5 ○ C ) specifies the interface of the test system towards the System Interface (TSI; Figure 5 ○. SUT, which includes HTTP and ROAP.. 2.1 DRM Test Management and Control (TMC). The TMC consists of three entities: Test Management (TM; Figures 5 ⑥), Test Logging (TL; Figure 5 ⑦) and External CoDecs (ECDs; Figure 5 ⑧). The TM is responsible for controlling the creation and the execution of tests. In DRM test execution, the TM invokes the DRM modules (e.g., tc_ConRoap module which will be described in Figure 7) to propagate the module parameters and/or extra testing information to the TE.. 8.

(16) Figure 6. Graphical test log for DRM registration.. The TL is responsible for maintaining the test log, such as the logging information about test component creation, start and termination, and data delivery to/from the SUT. The logging requests to the TL are posted externally from the TE or internally from the TM. Figure 6 shows a graphical test log that describes the interactions between MTC (Main Test. 9.

(17) Component, i.e. NTP-DRMT; Figure 6 ①) and SYSTEM (i.e. SUT; Figure 6 ②) based on the registration test case. When NTP-DRMT receives an HTTP_GET message (Figure 4 ① and Figure 6 ③) from the SUT, NTP-DRMT verifies the HTTP_GET message and replies a ROAP Trigger message (Figure 4 ② and Figure 6 ⑤) to the SUT. Then NTP-DRMT 6 ), verifies this message, receives the Device Hello message (Figure 4 ③ and Figure 6 ○ 8 ). Upon receipt of the Register and replies a RI Hello message (Figure 4 ④ and Figure 6 ○ 9 ), NTP-DRMT verifies this message and Request message (Figure 4 ⑤ and Figure 6 ○ 11 ). Every “match” box replies a Register Response message (Figure 4 ⑥ and Figure 6 ○ 4 , ○ 7 and ○ 10 ) indicates that the received message matches the pass criteria (Figure 6 ○ 12 ) indicates described in the conformance test specification. The final “pass” box (Figure 6 ○. that the SUT passes this test case.. The ECDs are invoked by the TE for encoding the TTCN-3 values into the bitstrings to be sent to the SUT or decoding the bitstrings sent from the SUT into the TTCN-3 values. Specifically, the TE passes the TTCN-3 values to an appropriate encoder to produce the encoded data. The received data is passed to an appropriate decoder to translate the received data into the TTCN-3 values. In NTP-DRMT, there are two ECDs in the DRM_Codec.java file; one for the HTTP procedure and the other for the ROAP procedure. These codecs are implemented in JAVA language so that they can be easily ported to different test systems. These two ECDs will be described in Section 4.. 2.2. DRM TTCN-3 Executable (TE). The TE consists of two interacting entities, Executable Test Suite (ETS; Figure 5 ⑨) and 10.

(18) TTCN-3 Runtime System (T3RTS; Figure 5 ⑩), to execute the DRM test cases. The T3RTS manages the ETS and interacts with the TMC, the SA and the PA. The T3RTS starts the execution of the DRM modules in the ETS. Figure 7 illustrates the ETS structure that classifies the DRM modules into two groups: conformance, and interoperability. Each module consists of a set of related test cases. For example, in the conformance group, the ROAP related conformance test case (e.g. DRM_2_con_5) is implemented in the tc_ConRoap module. This test case is invoked by the T3RTS when NTP-DRMT receives an HTTP_GET message (which is described in Section 1.3) to trigger the registration procedure.. Figure 7. The structure of the DRM ETS.. 11.

(19) 2.3. DRM SUT Adapter (SA). The SA adapts the communications between the TE and the SUT. The SA interacts with the 3 ) and pt_roap TE through the TRI. Specifically, the test component ports pt_http (Figure 8 ○ 4 ) that are mapped to the socket HTTPSocket (Figure 8 ○ 5 ) in the SA. The SA (Figure 8 ○. binds the socket to the TSI port 8080 for the interaction with the SUT. To correctly deliver the HTTP and the ROAP messages to and from the SUT, the TE calls the TRI functions (to be described in Section 3.2) to associate the test component ports with the TSI port. Also, the TE 1 and ○ 2 ) for the message encoding/decoding. invokes the ECDs (Figure 8 ○. Figure 8. Interaction between the SA and the TE in NTP-DRMT. 12.

(20) The SA is responsible for propagating the DRM requests (e.g., sending a ROAP message through the pt_roap.send function) from the TE to the SUT and notifying the TE of any received test events form the SUT (e.g., receiving a ROAP message through the 6 ). pt_roap.receive function) by buffering them in the TE’s port queues (Figure 8 ○. 13.

(21) Chapter 3 TTCN-3 Interfaces for DRM. This section elaborates on the NTP-DRMT control and runtime interfaces. We first describe the TTCN-3 Control Interface (TCI), and then the TTCN-3 Runtime Interface (TRI).. 3.1 The TTCN-3 Control Interface (TCI) for DRM. The TCI between the TE and the TMC has three sub-interfaces: Test Management Interface (TCI-TM), Test Logging Interface (TCI-TL) and Coding/Decoding Interface (TCI-CD). The TCI-TM supports the operations for controlling the test execution and providing module parameters. The TCI-TM program segment in Figure 9 illustrates some DRM module 1 assigns the test system port HTTP_PORT with the value 8080. parameters. Figure 9 ○ 2 assigns the test system Uniform Resource Locator (URL). Figure 9 ○ 3 assigns Figure 9 ○. the maximum waiting time between two received messages with the value 30.0 (seconds).. 4 ―○ 6 ) displays the descriptions of the parameters to the The extension function (Figure 9 ○. tester and reminds the tester that these parameters can be changed. If the parameters are modified, the updated parameters are provided to the test system as the module parameters through the TCI-TM.. 14.

(22) Figure 9. An example of DRM module parameter.. The TCI-TL includes the operations for retrieving the information about the test execution. Figure 10 illustrates a TCI-TL program segment that checks whether the signature is correct 1 , and logs the error if the signature is incorrect in the received ROAP message. In Figure 10 ○. NTP-DRMT checks if the signature in the received message is correct. If yes, NTP-DRMT replies a response message (Figure 10. 1.1. ). Otherwise, NTP-DRMT logs the error information. 2 ). and shows the error message in the test log (Figure 10 ○. Figure 10. DRM test logging example.. 15.

(23) The TCI-CD provides the operations to access codecs. In NTP-DRMT, TCI-CD is implemented in DRM_Codec.java described in Section 2.1. Parts of the program are listed 3 is executed in Figure 11. In this example, if no encoding rule is matched, then Figure 11 ○ 1 , an HTTP message is encoded as follows. Figure for the exception handling. In Figure 11 ○. 11. 1.1. ― 1.5 construct the HTTP message structure and append content, and set the content. type. Figure 11. 1.6. 2 generates a byte string from this HTTP message structure. Figure 11 ○. encodes a ROAP message, and the details are omitted.. Figure 11. DRM encode operation.. The DRM decode operation invoked by the TE decodes a message according to the decoding 1 rules and returns a TTCN-3 value. Parts of the program are listed as follows. Figure 12 ○ 2 decode the message as an HTTP or a ROAP message according to the message type and ○. 16.

(24) 1 , the HTTP message which is set in the TRI (Section 3.2). For example, in Figure 12 ○. decodes into a structured TTCN-3 value. Figure 12 Figure 12. 1.3. 1.2. sets the “msgType” to HTTP_GET, and. retrieves the Uniform Resource Identifier (URI).. Figure 12. DRM decode operation.. 3.2. The TTCN-3 Runtime Interface (TRI) for DRM. The TRI supports the communication of the TE with the SUT [13]. This interface is implemented in the SA to initialize the TSI and establish connections to the SUT. The TRI is implemented in a JAVA program DRM_TestAdapter.java consisting of the connection and the communication operations shown in Figure 13.. 17.

(25) Figure 13. DRM adapter operation. 18.

(26) The connection operations include map and unmap operations. Through the connection operations, the test component ports are mapped/unmapped to the TSI ports. An example is 1 ) called by the TE when TE executes the map operation the triMap function (Figure 13 ○ 1 ). This operation instructs the SA to establish a dynamic connection to the SUT. (Figure 15 ○. The TRI also supports the communication operations which are used to exchange messages with the SUT. The communication operations include enqueue and send operations. An 2 ) called by the SA after SA has example is the triEnqueueMsg function (Figure 13 ○. received a message from the SUT. When receiving an HTTP_GET message, this operation passes the message to the test component port of the TE (i.e., pt_http) and sets the message type HttpMsg. When receiving other messages, this operation passes these messages to pt_roap and sets the message type RoapMsg. Note that the test component port has been mapped to the TSI port beforehand. Another example is the triSend function (Figure 13 4 ) called by the TE when the TE executes the send operation (Figure 16 ○ 4 ). This operation ○. instructs the SA to send a message to the SUT. For DRM testing, two types of messages are sent by the triSend function: DRMRoapMsg for ROAP and DRMHttpMsg for HTTP.. 19.

(27) Chapter 4 A DRM Conformance Test Scenario. We use a conformance test case “missing States in RI Hello processing” to show how the DRM test suites are implemented. This test case verifies if the SUT correctly handles an incorrect RI Hello message without “Status" in the DRM registration procedure. The “Status” is used to indicate if the preceding request was successfully or not. If the SUT receives this message, it should display an error message and terminate the connection.. We utilize a Finite State Machine (FSM) to illustrate how the conformance test case “missing States in RI Hello processing” is implemented. Figure 14 shows the state diagram of the DRM conformance test case “missing States in RI Hello processing”. z. At State 1 (Waiting for HTTP_GET), if the HTTP_GET message is received from the SUT, the TE sends a ROAP Trigger message to the SUT and changes the FSM to State 2 (Waiting for Device Hello). If any ROAP message is received at State 1, the TE sets the verdict to “fail” and stops the FSM at State 4 (Test Fail). If the timer expires and the TE does not receive any message, the TE sets the verdict to “inconc” and stops the FSM at State 3 (Test Inconclusive).. z. At State 2, if the Device Hello message sent from the SUT is correct, then the TE sends an incorrect RI Hello message to the SUT and changes the FSM to State 5 (Waiting for Tester Post Result). If an HTTP_GET message is received at this state, the TE resends the ROAP Trigger message and waits for the Device Hello message. If an incorrect Device Hello message is received at this state, the TE sets the verdict to “fail” and stops the FSM at State 4. If the timer expires, the TE sets the verdict to “inconc” and stops the FSM at State 3. 20.

(28) z. State 3 is the “Test Inconclusive” state.. z. State 4 is the “Test Fail” state.. z. At State 5, if the tester reports pass, the TE sets the verdict to “pass” and changes the FSM to State 6 (Test Pass). If the tester reports fail, the TE sets the verdict to “fail” and stops the FSM at State 4.. z. State 6 is the “Test Pass” state.. Figure 14. DRM test case “missing States in RI Hello processing” state diagram.. Figure 15 illustrates the program segment for the test case. When the test starts, the TE first 1 ; the triMap maps the two test component ports to the test system ports (Figure 15 ○ 2 ) that operation at the TRI is invoked). Then it pops up an action window (Figure 15 ○ 1 ) what the test case is and asks the tester to send an notifies the tester (Figure 3 ○ 2 ). In Figure 15 ○ 3 , the TE sets the waiting HTTP_GET message from the SUT (Figure 3 ○ 4 ) to time. Then the TE invokes the f_DRM_2_con_5_a_rcvMsg function (Figure 15 ○. check whether the received messages from the SUT are correct. 21.

(29) Figure 15. DRM test case “missing States in RI Hello processing”.. In the f_DRM_2_con_5_a_rcvMsg function, the t_tMsg timer starts at the PA (Figure 1 ). When an HTTP_GET message from the SUT is received, the pt_http.receive 16 ○ 2 ) and the TE invokes the decode operation in Figure 12. function is executed (Figure 16 ○ 3 ), After the message is decoded, the TE stops the t_tMsg timer at the PA (Figure 16 ○ 4 ) to send a ROAP Trigger to the SUT, and invokes f_sndRegTrig function (Figure 16 ○ 7 . If a ROAP message is received (Figure 16 ○ 5 ), the test result goes to execute Figure 16 ○. (SC_FAIL) is returned. If the TE does not receive any message from the SUT after the 22.

(30) 6 ) and the t_tMsg timer expires, the PA notifies the TE of this timeout event (Figure 16 ○. f_DRM_2_con_5_a_rcvMsg function returns SC_TIME_OUT. The TE sets the verdict to 6 ) to indicate that an inconsistent exception occurs. “inconc” (Figure 15 ○. 8 ), then the TE resends the ROAP If the HTTP_GET message is received (Figure 16 ○ 9 ), then the TE Trigger to the SUT. If the TE receives a Device Hello message (Figure 16 ○. checks whether the header in the Device Hello message contains the DRM feature-tag 10 ). If any check of the message is failed, the “devhello version” (Figure 16 ○. f_DRM_2_con_5_a_rcvMsg function returns SC_FAIL to indicate the failure. If the received Device Hello message is correct, then the TE sends an incorrect RI Hello message (without. “Status"). to. the. SUT.. If. the. t_tMsg. timer. expires,. the. 11 ). f_DRM_2_con_5_a_rcvMsg function returns SC_TIME_OUT (Figure 16 ○. Finally, if the f_DRM_2_con_5_a_rcvMsg function returns SC_FAIL or SC_TIME_OUT, 5 and ○ 6 ). Otherwise, the TE pops the TE sets the verdict to “fail” or “inconc” (Figure 15 ○ 7 ) to notify the tester to check whether the result reported by up a confirm box (Figure 15 ○. the SUT is correct and report the result. Then the TE sets the verdict to “pass” or “fail” according to the tester’s report. After the verdict is set, the TE removes the bindings between 8 ) using the triUnmap the test component ports and the test system ports (Figure 15 ○. operation at the TRI.. 23.

(31) Figure 16. The f_DRM_2_con_5_a_rcvMsg function.. 24.

(32) Chapter 5 Conclusions. This thesis described the architecture and the operations of NTP-DRMT which is a DRM test system developed based on the TTCN-3 specifications. This system has been jointly developed by the National Telecommunications Program (NTP) and the Industrial Technology Research Institute (ITRI) in Taiwan. We used the DRM registration procedure to illustrate how the conformance test can be implemented in NTP-DRMT. The conformance and interoperability test cases are conformed to the OMA Enabler Test Specification (Conformance) for DRM-V2_0 [7] and the OMA Enabler Test Specification for DRM Interoperability [8]. Currently, 493 DRM tests cases have been developed in NTP-DRMT.. 25.

(33) Reference [1] Open Mobile Alliance, "DRM Specification", OMA-TS-DRM-DRM-V2_0- 2006 0303-A, 2006. [2] Open Mobile Alliance, "DRM Architecture", OMA-AD-DRM-V2_0-20060303-A, 2006. [3] Open Mobile Alliance, "DRM Content Format", OMA-TS-DRM-DCF-V2_0-20060303-A, 2006. [4] Open Mobile Alliance, "DRM Rights Expression Language", OMA-TS-DRM-REL-V2_ 0-20060303-A, 2006. [5] Open Mobile Alliance, "OMA DRM Requirements", OMA-RD-DRM-V2_0-20060303-A, 2006. [6] Open Mobile Alliance, "Enabler Release Definition for DRM V2.0", OMA-ERELD-DRM -V2_0-20060303-A, 2006. [7] Open Mobile Alliance, "Enabler Test Specification (Conformance) for DRM- V2_0", OMA-ETS-DRM_ CON_Test_Client-V2_0-20060615-C, 2006. [8] Open Mobile Alliance, "Enabler Test Specification for DRM Interoperability", OMA-ETS -DRM-INT- V2_0-20060704-C, 2006. [9] ETSI, "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language", ETSI ES 201 873-1, V3.1.1, 2005. [10] ETSI, " Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 2: TTCN-3 Tabular presentation Format (TFT)", ETSI ES 201 873-2 V3.1.1, 2005. [11] ETSI, " Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 3: TTCN-3 Graphical presentation Format (GFT)", ETSI ES 201 873-3 V3.1.1, 2005. [12] ETSI, " Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 4: TTCN-3 Operational Semantics", ETSI ES 201 873-4 V3.1.1, 2005. [13] ETSI, "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)", ETSI ES 201 873-5 V3.1.1, 2005. [14] ETSI, "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI )", ETSI ES 201 873-6, 26.

(34) V3.1.1, 2005. [15] ETSI, " Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 7: Using ASN.1 with TTCN-3", ETSI ES 201 873-7 V3.1.1, 2005. [16] Lin, Y.-B., Liang, C.-F., Chen, K.-H., Liao, H.-Y. "NTP-SIOT: A Test Tool for Advanced Mobile Services", IEEE Network. VOL 21; NUMB 1, pages 21-26, 2007. [17] Lin, Y.-B., Wang, C.C., Lu, C.H., Hsu, M.R. "NTP-PoCT: A Conformance Test Tool for Push-to-talk over Cellular Network", Wireless Communications and Mobile Computing. VOL 8; NUMBER 5, pages 673-686, 2008. [18] Anritsu Corporation, MD8470A Signaling Tester Product Introduction, http:// www.us.anritsu.com/products/ ARO/North/Eng/showProd.aspx?ID=659.. 27.

(35) Appendix A The conformance and interoperability test cases The conformance test cases Test case ID DRM-2.0-con-1 DRM-2.0-con-3 DRM-2.0-con-4 DRM-2.0-con-5 DRM-2.0-con-6 DRM-2.0-con-7 DRM-2.0-con-8 DRM-2.0-con-9 DRM-2.0-con-29 DRM-2.0-con-30 DRM-2.0-con-31 DRM-2.0-con-32 DRM-2.0-con-33 DRM-2.0-con-34 DRM-2.0-con-35 DRM-2.0-con-35 DRM-2.0-con-36 DRM-2.0-con-37 DRM-2.0-con-38 DRM-2.0-con-40 DRM-2.0-con-41 DRM-2.0-con-42 DRM-2.0-con-43 DRM-2.0-con-44 DRM-2.0-con-45 DRM-2.0-con-46 DRM-2.0-con-47 DRM-2.0-con-48 DRM-2.0-con-49 DRM-2.0-con-50 DRM-2.0-con-51 DRM-2.0-con-52 DRM-2.0-con-53 DRM-2.0-con-54 DRM-2.0-con-55 DRM-2.0-con-56 DRM-2.0-con-57 DRM-2.0-con-58. Test case description ROAP trigger with expired RI context Missing Signature in Leave Domain trigger Invalid Signature in Leave Domain trigger Missing Status attribute in ROAP Response Status ≠ Success in ROAP Response Missing Signature in ROAP Response Invalid Signature in ROAP Response 1-pass RO Response processing reception while expired RI context Missing Session ID in Register Response processing Invalid Session ID in Register Response processing Missing Device ID in ROAP response; 2 pass RO acquisition and Join Domain Invalid Device ID in ROAP response; 2 pass RO acquisition and Join Domain Missing Device ID in 1-pass RO Response processing Invalid Device ID in 1-pass RO Response processing Missing Device Nonce in ROAP response Missing Device Nonce in Leave Domain Response processing Invalid Device Nonce in ROAP response Missing RI ID in ROAP response Invalid RI ID in ROAP response Install Device RO from RO Response processing; Invalid Signature Install Device RO from RO Response processing; Missing MAC element Install Device RO from RO Response processing; Invalid MAC element Install Device RO from RO Response processing; Missing RI ID Install Device RO from RO Response processing; Invalid RI ID Install Device RO from RO Response processing; Missing Signature Install Device RO from RO Response processing; Invalid Signature Install Device RO from RO Response processing; Missing MAC element Install Device RO from DCF; Invalid MAC element Install Device RO from DCF; Missing RI ID Install Device RO from DCF; Invalid RI ID Install Device RO from DCF; RI Context Expired Consume rights in Device RO; Invalid Hash value Install Domain Context; Missing MAC Install Domain Context; Invalid MAC Install Domain Context; Missing RI ID in DomainKey Install Domain Context; Invalid RI ID in DomainKey Delete Domain Context Install Domain RO; No valid RI context with corresponding RI ID 28.

(36) DRM-2.0-con-59 DRM-2.0-con-60 DRM-2.0-con-61 DRM-2.0-con-62 DRM-2.0-con-63 DRM-2.0-con-64 DRM-2.0-con-65 DRM-2.0-con-66 DRM-2.0-con-67 DRM-2.0-con-68 DRM-2.0-con-69 DRM-2.0-con-70 DRM-2.0-con-71 DRM-2.0-con-72 DRM-2.0-con-73 DRM-2.0-con-74 DRM-2.0-con-75 DRM-2.0-con-76 DRM-2.0-con-77 DRM-2.0-con-78 DRM-2.0-con-79 DRM-2.0-con-80 DRM-2.0-con-81 DRM-2.0-con-82 DRM-2.0-con-83 DRM-2.0-con-85 DRM-2.0-con-86 DRM-2.0-con-87 DRM-2.0-con-88 DRM-2.0-con-89. Install Domain RO; Missing Signature Install Domain RO; Invalid Signature Install Domain RO; Missing Domain ID Install Domain RO; Invalid Domain Generation Install Domain RO; Device not in the domain Install Domain RO; Missing MAC. Install Domain RO; Invalid MAC. Install Domain RO; RI Context Expired Replay protection – Stateful RO with RITS; Future RITS Replay protection – Stateful RO with RITS; In Replay cache Replay protection – Stateful RO with RITS; Early RITS Replay protection – Stateful RO without RITS; In Replay cache Parent Rights object; Invalid Rights issuer Nonce generation on Device without system shutdown Nonce generation on Device with system shutdown Wrong permissions for an image object Wrong permissions for a sound object Wrong permissions for an application object Unknown permissions Export permissions ("move") for DCFs with stateless rights object Export permissions ("copy") for DCFs with stateless rights object Export permissions ("move") for DCFs with stateful rights object Export permissions ("copy") for DCFs with stateful rights object Export permissions not present for DCF Instant Preview Erroneous Count constraint Erroneous Timed-Count constraint Erroneous Datetime constraint Erroneous Interval constraint Erroneous Accumulated constraint. The Interoperability test cases Test case ID DRM-2.0-int-1 DRM-2.0-int-2 DRM-2.0-int-3 DRM-2.0-int-4 DRM-2.0-int-5 DRM-2.0-int-6 DRM-2.0-int-7 DRM-2.0-int-8 DRM-2.0-int-10. Test case description To test “Forward Lock” DRM 1.0 functionality. To test DRM 1.0 “Combined Delivery” functionality To test DRM 1.0 “Separate Delivery” functionality To test RO Registration and RO Acquisition To test RO Registration with existing RI Context To test RO Acquisition without existing RI Context To test 1-pass RO Acquisition with existing RI Context To test 1-pass RO Acquisition without existing RI Context To test a situation where an RO is included in the DCF To test behavior in the presence of a group RO for multiple DCFs, using DRM-2.0-int-11 the Group ID mechanism To test behavior in the presence of an individual RO for a content item DRM-2.0-int-12 which has a Group ID To test behavior in the presence of several rights objects for one piece of DRM-2.0-int-13 content 29.

(37) DRM-2.0-int-14 DRM-2.0-int-15 DRM-2.0-int-16 DRM-2.0-int-17 DRM-2.0-int-18 DRM-2.0-int-19 DRM-2.0-int-20 DRM-2.0-int-21 DRM-2.0-int-22 DRM-2.0-int-23 DRM-2.0-int-24 DRM-2.0-int-25 DRM-2.0-int-26 DRM-2.0-int-27 DRM-2.0-int-28 DRM-2.0-int-29 DRM-2.0-int-30 DRM-2.0-int-31 DRM-2.0-int-32 DRM-2.0-int-33 DRM-2.0-int-34 DRM-2.0-int-35 DRM-2.0-int-36 DRM-2.0-int-37 DRM-2.0-int-38 DRM-2.0-int-39 DRM-2.0-int-40 DRM-2.0-int-41 DRM-2.0-int-42 DRM-2.0-int-43 DRM-2.0-int-44 DRM-2.0-int-45 DRM-2.0-int-46. To test behavior in the presence of several rights objects for one piece of content To test DRM Agent’s capability to process Multipart DCFs from the RI To test behavior in the presence of multiple ROs for a multipart DCF To test behavior when different content items in a multipart DCF are associated with different groups To test “Superdistribution” functionality. The protected content is sent from one DRM Agent to another. The rights object is obtained by ROAP session to the rights issuing service. To test the TransactionID mechanism in connection with Superdistribution To test <display> and <print> permissions To test <play> permission To test <execute> permission for an application object To test <count> constraint for a DCF To test <timed-count> constraint for a DCF To test <datetime> constraint for a DCF To test <interval> constraint for a DCF To test <accumulated> constraint for a DCF To test <individual> constraint for a DCF To test <system> constraint for a DCF To test the effect of having multiple constraints To test the REL Permission Model in the case that the rights include a stateful top level constraint Initiate ROAP from DCF Preview Header with existing RI Context & domain name NOT in Domain Name Whitelist Initiate ROAP from DCF Preview Header with existing RI Context & domain name in the Domain Name Whitelist To test inheritance model when stateful constraints are involved To test a case where the Parent Rights Object To test inheritance model when a child RO is a group RO Trigger-initiated domain join without existing RI Context Trigger-initiated domain join with valid RI Context and no existing Domain Context for this RI Automatically-initiated domain upgrade with valid RI Context and existing Domain Context for this RI Trigger-initiated domain join with valid RI Context and existing Domain Context for this RI Domain RO Acquisition with existing RI Context To test delivering the DomainRO inside a DCF To test if different devices related with the same domain are able to share DCFs Device leaves a domain after receiving a LeaveDomain trigger Initiate ROAP from DCF Silent Header with existing RI Context and domain name NOT in Domain Name Whitelist Initiate ROAP from DCF Silent Header with existing RI Context and domain name NOT in Domain Name Whitelist. 30.

(38)