DRM Renewability & Interoperability

Transcription

1 DRM Renewability & Interoperability Takanori Senoh, Takafumi Ueno, Takuyo Kogure Matsushita Electric Industrial Co., Ltd Kadoma, Kadoma, Osaka , Japan jp.panasonic.com, Shengmei Shen, Ming Ji, Jing Liu, Zhongyang Huang Panasonic Singapore Laboratories Pte Ltd. Blk1022 Tai Seng Av# Tai Seng Ind Est, Singapore Craig A. Schultz Multimedia Architectures. 1-1 Shimocho, Isogo, Yokohama, Kanagawa , Japan Abstract Currently existing Digital Rights Management systems employ proprietary methods to protect contents. Hence they have no capability to inter-operate with each other. This causes great inconvenience for users who want to subscribe to contents from different providers. In this paper, a new Intellectual Property Management & Protection method ( Extension) is introduced, which enables users to enjoy content services delivered from different providers which are based on individual content protection mechanisms. This method is proposed to ISO/IEC JTC1/SC29/WG11 (MPEG) and the standardization is in the final stage. is also proposed to DVB-CPT (Digital Vide Broadcasting-Copy Protection Technologies) and TV Anytime Forum. ISMA (Internet Streaming Media Alliance) adopted in ISMA1.0 Encryption & Authentication specification. 1. Introduction Recent digital technology has been enabling high speed communication throughout the Internet or Intranet including wired and wireless connections. Through these networks, people are able to enjoy multimedia content subscription from content providers. However, current content providers adopt proprietary content protection mechanisms. This brings an obstacle which prevents users to easily access different content providers. Users have to install multiple content subscription systems depending on the providers. It forces a large inconvenience, especially to mobile terminals such as cellular phones, PDAs, portable recorders or viewers, as these devices do not have large memory capacity nor can support high power consumption so as to keep themselves small and light weight. Because of this inconvenience, a common content protection mechanism which can be widely used is strongly required from the consumer s point of view. However, a common protection mechanism contains the risk that once the system is broken by any malicious hacker, the whole content delivery systems is jeopardized their security, consequently from content provider s point of view, different content protection mechanisms are preferable. In order to solve this dilemma, we propose a new method, Intellectual Property Management & Protection () Extension system which supports inter-operability between servers and terminals, while maintaining each protection system individually. This method specifies information which notifies clients the information as to how the contents are protected. With this information the client terminals are reconfigured to decode the protected contents. If any decoding tools such as cipher decoder or watermark detector are not installed in the terminal, the URLs where they can be downloaded are provided in the information. Additionally, the specifications support the delivery of necessary decoders within the content itself. In order to utilize this functionality, the client terminals have to equip themselves with tool downloadability. As the current electronics devices such as cellular phones or digital TVs are already installed with the capability to download software like Java applets or dedicated executable modules, this will not be a big burden for them. With this downloadability, any proprietary content protection system can easily upgrade its security tools and hence the robustness of the protection system is highly maintained. This method was proposed at ISO/IEC JTC1/SC29/WG11 in Since then, the specification has been standardized as ISO/IEC Amendment 3 (MPEG-4 Extension), (MPEG-4 ) and as ISO/IEC (MPEG-2 ). The has been proposed to DVB-CPT for the CPCM (Content Protection /04/$ IEEE. 424

2 and Copy Management) solution and to TV Anytime Forum for its RMP (Right Management and Protection) solution. has been adopted in ISMA (Internet Streaming Media Alliance) 1.0 Encryption and Authentication specification. In section 2, the Architecture concept is described. terminal architecture is explained in section 3. Section 4 explains Information and its functionality. Section 5 lists the merits of architecture. Section 6 concludes this paper. 2. architecture concept As the basic idea of MPEG-2 and MPEG-4 Extension are the same, MPEG-4 Extension is mainly described below. Figure 1 illustrates the concept of MPEG architecture. The main Information is Tool List, Descriptor and elementary Stream (ES). Serv er Figure 1. Concept of Architecture 2.1. Tool List Information Tool List Descriptor Contents Tool List carries the information of the tools required by the terminal to decode the protected content. This mechanism enables the terminal to select or renew the tools, or to retrieve the tools when they are missing Descriptors ES This is a part of the MPEG-4 object descriptors that further describe how an object can be accessed and decoded. Descriptors also describe how to load and configure the Tools that are used to protect the object. Tool IDs are used to identify Tools. An independent registration authority (RA) is required so that any party can register its own Tools and identify them without collisions Elementary Stream (ES) Tool Terminal specific data such as Key Data or Rights Data are carried in the Elementary Stream (ES). All MPEG objects are represented by elementary streams, which can refer to each other. These special elementary streams are used to convey specific data. Their syntax and semantics are explained in section Secure messaging framework Extension framework is based on messages. Interaction between terminal and Tools are realized through messages via a conceptual entity called Message Router. Syntax and semantics of the messages are clearly defined to ensure full interoperability. Mutual authentication and secure messages are also introduced to realize a secure framework. Key management, user registration/authentication are not defined in MPEG-4 Extension. They are up to the Tools on top of MPEG-4 Extension. This enables using different Tools for different application, maintaining interoperability. 3. terminal architecture and walkthrough 3.1. Terminal architecture Figure 2 shows the terminal architecture under MPEG-4 Extension framework: In Figure 2, the Tool list is included in the Initial Object Descriptor (IOD), stream arrives as an elementary stream multiplexed with MPEG-4 content stream. The Tool Manager manages Tools within the terminal while Message Router routes messages among terminal and Tools. The incoming content is de-multiplexed in the DEMUX. Audio, Video, OD (Object Descriptor) and BIFS (BInary Format For Scene) bitstreams are then supplied to each Decoding Buffer () and decoded. The decoded audio and video data are fed to each of Audio Composition Buffer (CB) and Video CB, then composed in Compositor together with the decoded OD Walkthrough 1) User requests specific content The manner in which content is requested is out of scope of MPEG-4 Extension standard. However, following recommendations are made in order that different parts of the content are received and used: Requirements on the Terminal should be placed with or before media requirements on the Terminal. Content Access Information and/or restrictions should precede Content Stream download information /04/$ IEEE. 425

3 Content Stream MPEG-4 Content Stream(s) Stream(s) IOD Tool List Tool ID Content Request Content Delivery DMIF DEMUX Audio Video OD BIFS User Terminal Audio Video OD BIFS Audio CB Video CB BIFS CB Compositor Renderer BIFS Tree / Scene Graph Alternate Tool(s) Parametric Descriptionl(s) Tool List / Tool ES Message Descriptor System Message Router / Tool Manager Tool ESD Tool Manager Interface Message Router Interface Obtain Missing Tools Tools Messages Missing Tools Tool A Tool B Tool C Fig. 2: terminal architecture 2) tools description access The terminal accesses the Tool List carried in IOD in MPEG-4 system stream. Using the Tool List, the Terminal determines the Tools required for consuming the content. 3) tools retrieval If the tools are available locally at the terminal, proceed to step 4). The terminal attempts to obtain the Missing Tools. Some Missing Tools may be carried in the Content itself. Otherwise, the Tool must be obtained remotely. In this case, the terminal accesses an implementation specific database for a location of the missing Tool. A secure communication channel is set-up between the terminal and the Tool location. The terminal implementation provides information about its platform and the Tool database identifies a compatible Tool implementation. The Tool Manager accesses and acquires the missing Tools. The newly acquired tools are made available for use in the terminal. 4) Instantiation of tools The terminal instantiates the tool(s) locally or remotely as indicated by Descriptors with its control point and the sequence code (priority). Different Tools can operate at the same or different control point, acting on the same or different streams. The instantiated Tools are provided with initial Information from the content via their descriptors. One or more Tools, identified in the Content, may use Information to determine security requirements for content access, then to monitor and to facilitate the establishment and maintenance of these security requirements in inter-tool communication. 5) initialization and update In parallel with Content Consumption The Message Router routes Information to the Tools. The terminal consumes the content if allowed by the requisite Tools. During content consumption, the complete walkthrough can be requested again. Requests for content consumption are implicit within the process, or are explicitly requested by the User. Specific Information can be made normative outside this architecture. This architecture supports both transparent and opaque Information. 4. information and its functionality information is carried in IOD or Stream in the content stream, depending on its functionality. In Figure 3, the detailed information is shown and also the relation between them is illustrated Tool List /04/$ IEEE. 426

4 IOD Tool List Tool ESD Descriptor(s) Tool IDs Parametric Description Control Graph OD A OD B Alternative Tool... IDs ES 1 ES 2 Informative URL... Tool Control Descriptor(s) ID Points Info Content Stream OD Stream Stream MPEG-4 Content Stream(s) Data Various Data Opaque Data Key Data Rights Data Tool Init Data Fig. 3: Structure of MPEG-4 system content The idea of the Tool List is the notification of necessary tools for the protected content decoding. MPEG-4 Extension defines with a SDL (Syntactic Description Language) descriptor _ToolListDescriptor in the IOD which supports indication of independent or alternative Tools required to consume the protected content. The IOD is used to carry Tool List since IOD arrives ahead of OD, BIFS and other elementary streams, hence allows the Tool Manager to retrieve and make sure every Tool is installed before receiving the content stream. For each tool in the Tool List, the following information is provided: Tool Identifier: identifies necessary tools. Parametric Description: optionally identifies tools with the parameters. Alternative Tool IDs: identifies alternative tools. Informative URL: addresses where the tool is downloaded. The above structure of Tool List provides the terminal enough information to retrieve a tool. It also allows a flexible way to identify an tool via its alternatives or parametric descriptions Tool ES One or more Binary Representations of Tools may be carried directly or by reference in an MPEG presentation data as an _ToolES. A StreamType, ToolStream is defined to carry binary code of Tools. The value assigned to this StreamType is set as 0x0B, from the current ISO-reserved range. One implementation of a given tool is carried as the payload of one Tool stream. The representation format, package information and the Tool ID are specified in ConfigDescriptor in the associated ESD(Elementary Stream Descriptor). _ToolESs shall be referred through the IOD. The Tool Manager serves as a decoder for Tool Streams. Tools carried within _ToolESs can be part of the Terminal resources. They are then installed, used and retained at the discretion of the Terminal implementation. In order that the downloaded tools can be installed or otherwise made available for the Terminal implementation, it shall be referred via its Tool ID just like any other Tools Descriptor and its signaling Descriptor The signaling of protection scope and its control point is done by Descriptors and Descriptor Pointers. They provide a flexible indication and much functionality /04/$ IEEE. 427

5 The _Descriptor carries information for one or more Tool instances. It also contains optional instantiation information for one or more Tool instances. _Descriptors are conveyed in either initial object descriptors, object descriptors or object descriptor streams via _DescriptorUpdate commands. An _Descriptor may also be modified or updated through subsequent _DescriptorUpdate commands received through the OD stream. Each _Descriptor has an _ToolID. A zero, 0 value does not correspond to an Tool but is used to indicate the presence of a URL, otherwise, it describes and signals an tool protection. The control point where the Tool works is signaled by another element in _Descriptor. _Descriptor also allows carriage of data extended from _Data_BaseClass that delivers instantiation, configuration or other information to Tool instances Signaling with Descriptor The _DescriptorPointer appears in the ipmpdescptr section of an OD or ESD structures. The presence of this descriptor pointer in an OD indicates that all streams referred to by embedded ES_Descriptors are subject to protection and management by the Tool specified in the referring _Descriptor. The presence of this descriptor pointer in an ES_Descriptor indicates that the stream associated with this descriptor is subject to protection and management by the Tool specified in the referring _Descriptor. _DescriptorPointer also has an _ES_ID that is the ID of an stream that may carry messages intended for the tool specified in the referred _Descriptor. In case more than one stream is needed to feed the tool, several _DescriptorPointers can be given with the same _DescriptorID and different _ES_ID. If the _ES_ID is null, it means the tool does not require any stream. A value of 2^16-1 for _ES_ID indicates that this field should be ignored, meaning that the tool pointed to by this _DescriptorID may receive messages from any stream within the presentation (following content streams). By utilizing _Descriptor and _DescriptorPointers, the terminal can build an abstract Control Graph, which bears a tree-like hierarchy. Different Tools can be specified to protect different objects or different elementary streams under that object, at different control point or at the same control point but bearing a different sequence code Data Data is the information directed to a given Tool or terminal to enable, assist or facilitate its operation. Data includes not only a key but also usage rights, tool initialization information or mutual authentication information Places to carry Data Data can come from various sources. When it is carried in the content, it can be contained in _Message class in an Stream or _Descriptor. Data can also be generated by an Tool or terminal and delivered to other Tool or terminal as a payload of _MessageFromTool. All Data are extended from _Data_BaseClass which is elaborated below Data Base Class abstract aligned(8) expandable(2^28-1) class _Data_BaseClass: bit(8) tag= { bit(8) Version; bit(32) dataid; } Version indicates the version of syntax used in the Data and shall be set to 0x01. dataid used only when a derived class is carried in an _ToolMessageBase or _DeviceMessageBase derived message for the purpose of identifying the message. Tools replying directly to a message shall include the same dataid in any response. Tag indicates the tag for the extended data. The exact values for the extension tags are not specified in this paper Delivery of Data to Tools Data is routed using normative addressing methods. The addressee of a specific message is implicit either by bitstream context or by process context. In the MPEG-4 bitstream context, the addressee is the Tool whose identity is indicated in the message or descriptor header. Information is delivered at a specific time specified in the bitstream or implicitly delivered by process. Data carried in _Descriptor is delivered to the Tool declared in the descriptor. The Data is sent as a payload of message _DescriptorFromBitstream /04/$ IEEE. 428

6 Data carried in _Message class of Stream is delivered to the Tool declared in the _Descriptor whose _DescriptorID is indicated in the same _Message class. The Data is sent as a payload of message _MessageFromBitstream. Physical routing of information and context resolution are handled by an entity called Message Router. The Message Router abstracts all platform-dependent routing and delivery issues from the Tools. 4.5 Other messages MPEG-4 Extension further defines the other messages as follows. All these messages are extended from _ToolMessageBase. 1) Instantiation and notification messages 2) Event notification messages 3) processing messages 4) Authentication messages 5) User Interaction messages 6) Consumption permission messages These messages are used for the tool instantiation, tool event notification, tool initialization, tool data supply such as key data or rights data, tool authentication, user interaction and contents consumption permission. 5. Advantages of architecture The proposed architecture fulfils the following requirements: Flexibility: One can choose whatever algorithms to perform decryption, watermarking, user authentication or integrity checking. Dynamic operation: Various Tool protection can be signaled in the content with the help of Descriptor, control point and sequence code. Different Tools can operate at the same or different control point, acting on the same or different streams. Secure tools: Terminal and Tools can choose to perform mutual authentication using messages. Interoperability: By using a common set of messages, industry defined messaging API and message extension, different Tools can be easily plugged into the terminal and interact with each other. Renewability: By the usage of Tool List and Descriptor, one can easily renew a tool to perform protection. 6. Conclusion This paper introduced a new technology, (Intellectual Property Management & Protection) for DRM (Digital Rights Management) Renewability and Interoperability. is proposed to and is standardized as MPEG (Motion Picture coding Expert Group) -2/-4. Currently, MPEG-21 Architecture is discussing how to integrate the idea of and the other existing parts such as DID (Digital Item Declaration), DII (Digital Item Identification), REL (Rights Expression Language), etc. in it. offers flexibility, robustness and interoperability, which promotes the secure content delivery all over the world. can be used in combination with proprietary tools, which enables the implementation in various categories, while maintaining the worldwide interoperability. The authors thank Mr. Yoshiaki Kushiki and Mr. Fujio Nakajima of Matsushita Electric Industrial Co., Ltd, Mr. Hideyuki Oka of Panasonic Singapore Laboratories Pte Ltd and others who provided us this opportunity. References [1] ISO/IEC JTC1/SC29/WG11 MPEG, Text of ISO/IEC /FDIS, N5284, (Information technology Coding of audio-visual objects Part 13: Intellectual Property Management and Protection () extension), Shanghai, Oct [2] ISO/IEC JTC1/SC29/WG11 MPEG, Text of ISO/IEC /PDAM3, N5282, (Amendment to MPEG-4 system on Extension), Shanghai, Oct [3] ISO/IEC JTC1/SC29/WG11 MPEG, MPEG-4 Intellectual Property Management & Protection () Overview & Applications, N2614, Rome, Dec [4] ISO/IEC JTC1/SC29/WG11 MPEG, International Standard ISO/IEC Information Technology Generic Coding of Moving Pictures and Associated Audio, Part 1: Systems, 2001 [5] ISO/IEC JTC1/SC29/WG11 MPEG, MPEG-2 and MPEG-4 Extension Reference Software Architecture based on IM1, N4850, Fairfax, May, [6] ISO/IEC JTC1/SC29/WG11 MPEG, ISO/IEC /FDIS (MPEG-2 ), N5608, Pattaya, Mar, [7] ISO/IEC JT5C1/SC29/WG11 MPEG, ISO/IEC :2000/FDAM2 (MPEG-2 Amendment), N5604, Pattaya, Mar, [8] Ahmet M. Eskicioglu, John Town, and Edward J. Delp, Security of Digital Entertainment Content from Creation to Consumption, Proceedings of SPIE Applications of Digital Image Processing XXIV, San Diego, CA, July 31-August 3, [9] B.J. van Rijnsoever, Peter Lenoir, J.P.M.G. Linnartz, "Interoperable protection for digital multimedia content", invited paper in "Journal of VLSI Signal Processing - Systems for Signal, Image and Video Technology" special issue on Multimedia Communications, may /04/$ IEEE. 429