DRM renewability & interoperability - IEEE Xplore

0 downloads 0 Views 1MB Size Report
Matsushita Electric Industrial Co., Ltd. 1006 Kadoma, Kadoma, Osaka ... Panasonic Singapore Laboratories Pte Ltd. Blk1022 Tai Seng Av#04-3530 Tai Seng Ind ...
DRM Renewability & Interoperability Takanori Senoh, Takafumi Ueno, Takuyo Kogure Matsushita Electric Industrial Co., Ltd. 1006 Kadoma, Kadoma, Osaka 571-8501, Japan [email protected], ueno.takafumi@ jp.panasonic.com, [email protected] Shengmei Shen, Ming Ji, Jing Liu, Zhongyang Huang Panasonic Singapore Laboratories Pte Ltd. Blk1022 Tai Seng Av#04-3530 Tai Seng Ind Est, Singapore 534415 [email protected], [email protected], [email protected], [email protected] Craig A. Schultz Multimedia Architectures. 1-1 Shimocho, Isogo, Yokohama, Kanagawa 235-004, Japan [email protected] 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.

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 (IPMP 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. IPMP is also proposed to DVB-CPT (Digital Vide Broadcasting-Copy Protection Technologies) and TV Anytime Forum. ISMA (Internet Streaming Media Alliance) adopted IPMP in ISMA1.0 Encryption & Authentication specification.

In order to solve this dilemma, we propose a new method, “Intellectual Property Management & Protection (IPMP) Extension” system which supports inter-operability between servers and terminals, while maintaining each protection system individually. This method specifies IPMP 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 IPMP information. Additionally, the specifications support the delivery of necessary IPMP decoders within the content itself.

1. Introduction

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.

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.

0-7803-8145-9/04/$17.00 ©2004 IEEE.

This method was proposed at ISO/IEC JTC1/SC29/WG11 in 2000. Since then, the specification has been standardized as ISO/IEC 14496-1 Amendment 3 (MPEG-4 IPMP Extension), 14496-13 (MPEG-4 IPMP) and as ISO/IEC 13818-11(MPEG-2 IPMP). The IPMP has been proposed to DVB-CPT for the CPCM (Content Protection

424

and Copy Management) solution and to TV Anytime Forum for its RMP (Right Management and Protection) solution. IPMP has been adopted in ISMA (Internet Streaming Media Alliance) 1.0 Encryption and Authentication specification.

IPMP specific data such as Key Data or Rights Data are carried in the IPMP 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 IPMP specific data. Their syntax and semantics are explained in section 4.

In section 2, the IPMP Architecture concept is described. IPMP terminal architecture is explained in section 3. Section 4 explains IPMP Information and its functionality. Section 5 lists the merits of IPMP architecture. Section 6 concludes this paper.

2.4. Secure messaging framework IPMP Extension framework is based on messages. Interaction between terminal and IPMP 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.

2. IPMP architecture concept As the basic idea of MPEG-2 IPMP and MPEG-4 IPMP Extension are the same, MPEG-4 IPMP Extension is mainly described below. Figure 1 illustrates the concept of MPEG IPMP architecture. The main IPMP Information is IPMP Tool List, IPMP Descriptor and IPMP elementary Stream (ES). Serv er

IPMP Inf ormation

Key management, user registration/authentication are not defined in MPEG-4 IPMP Extension. They are up to the IPMP Tools on top of MPEG-4 IPMP Extension. This enables using different IPMP Tools for different application, maintaining interoperability.

Terminal

IPMP Tool List IPMP Descriptor

3. IPMP terminal architecture and walkthrough Contents

IPMP ES

Tool

3.1. Terminal architecture Figure 2 shows the terminal architecture under MPEG-4 IPMP Extension framework: In Figure 2, the Tool list is included in the Initial Object Descriptor (IOD), IPMP stream arrives as an elementary stream multiplexed with MPEG-4 content stream. The Tool Manager manages IPMP Tools within the terminal while Message Router routes messages among terminal and IPMP 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 (DB) 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.

Figure 1. Concept of IPMP Architecture

2.1. IPMP Tool List IPMP 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.

2.2. IPMP Descriptors This is a part of the MPEG-4 object descriptors that further describe how an object can be accessed and decoded. IPMP Descriptors also describe how to load and configure the IPMP Tools that are used to protect the object. Tool IDs are used to identify IPMP Tools. An independent registration authority (RA) is required so that any party can register its own IPMP Tools and identify them without collisions.

3.2. Walkthrough 1) User requests specific content The manner in which content is requested is out of scope of MPEG-4 IPMP Extension standard. However, following recommendations are made in order that different parts of the content are received and used: IPMP 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.

2.3. IPMP Elementary Stream (ES)

0-7803-8145-9/04/$17.00 ©2004 IEEE.

425

IOD

Content Delivery

Tool List Tool ID

Audio Decoder

Audio CB

Video DB

Video Decoder

Video CB

OD DB

OD Decoder

BIFS DB

BIFS Decoder

BIFS CB

IPMP DB

IPMP System Message Router / Tool Manager

IPMP Tool List / Tool ES

Tool ESD

BIFS Tree / Scene Graph

IPMP Descriptor

IPMP Message

Alternate Tool(s) Parametric Descriptionl(s)

Audio DB

Renderer

IPMP Stream(s)

Content Request

DEMUX

MPEG-4 Content Stream(s)

User Terminal

DMIF

Compositor

Content Stream

Tool Manager Interface

Message Router Interface

Obtain Missing Tools

IPMP Tools Messages Missing Tools

IPMP Tool A

IPMP Tool B

IPMP Tool C

Fig. 2: IPMP terminal architecture their IPMP descriptors. One or more Tools, identified in the Content, may use IPMP 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.

2) IPMP tools description access The terminal accesses the IPMP Tool List carried in IOD in MPEG-4 system stream. Using the IPMP Tool List, the Terminal determines the IPMP Tools required for consuming the content.

5) IPMP initialization and update – In parallel with Content Consumption The Message Router routes IPMP Information to the IPMP Tools. The terminal consumes the content if allowed by the requisite IPMP 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 IPMP Information can be made normative outside this architecture. This architecture supports both transparent and opaque IPMP Information.

3) IPMP tools retrieval If the tools are available locally at the terminal, proceed to step 4). The terminal attempts to obtain the Missing IPMP 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 IPMP Tool Manager accesses and acquires the missing IPMP Tools. The newly acquired tools are made available for use in the terminal.

4. IPMP information and its functionality IPMP information is carried in IOD or IPMP Stream in the content stream, depending on its functionality. In Figure 3, the detailed IPMP information is shown and also the relation between them is illustrated.

4) Instantiation of IPMP tools The terminal instantiates the IPMP tool(s) locally or remotely as indicated by IPMP 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 IPMP Information from the content via

0-7803-8145-9/04/$17.00 ©2004 IEEE.

4.1. IPMP Tool List

426

Tool IDs IOD IPMP Tool List IPMP Tool ESD IPMP Descriptor(s)

... ...

Parametric Description

IPMP Control Graph OD A OD B

Alternative Tool IDs Informative URL

IPMP Descriptor(s)

Content Stream

...

ES 1

ES 2

... Tool Control IPMP ID Points Info

... ...

Various IPMP Data Opaque Data

OD Stream

Key Data

IPMP Data

IPMP Stream

Rights Data

MPEG-4 Content Stream(s)

Tool Init Data

... ...

... ...

Fig. 3: Structure of MPEG-4 system content The idea of the IPMP Tool List is the notification of necessary tools for the protected content decoding. MPEG-4 IPMP Extension defines with a SDL (Syntactic Description Language) descriptor IPMP_ToolListDescriptor in the IOD which supports indication of independent or alternative IPMP Tools required to consume the protected content. The IOD is used to carry IPMP Tool List since IOD arrives ahead of OD, BIFS and other elementary streams, hence allows the IPMP Tool Manager to retrieve and make sure every IPMP Tool is installed before receiving the content stream.

One or more Binary Representations of IPMP Tools may be carried directly or by reference in an MPEG presentation data as an IPMP_ToolES. A StreamType, “IPMPToolStream” is defined to carry binary code of IPMP 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 IPMP Tool stream. The representation format, package information and the IPMP Tool ID are specified in DecoderConfigDescriptor in the associated ESD(Elementary Stream Descriptor).

For each tool in the IPMP Tool List, the following information is provided:

IPMP_ToolESs shall be referred through the IOD. The IPMP Tool Manager serves as a decoder for IPMP Tool Streams. IPMP Tools carried within IPMP_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 IPMP Tool ID just like any other IPMP Tools.

IPMP Tool Identifier: identifies necessary IPMP tools. Parametric Description: optionally identifies tools with the parameters. Alternative Tool IDs: identifies alternative tools. Informative URL: addresses where the tool is downloaded.

4.3. IPMP Descriptor and its signaling

The above structure of IPMP Tool List provides the terminal enough information to retrieve a tool. It also allows a flexible way to identify an IPMP tool via its alternatives or parametric descriptions.

4.3.1 IPMP Descriptor The signaling of protection scope and its control point is done by IPMP Descriptors and IPMP Descriptor Pointers. They provide a flexible indication and much functionality.

4.2. IPMP Tool ES

0-7803-8145-9/04/$17.00 ©2004 IEEE.

427

The IPMP_Descriptor carries IPMP information for one or more IPMP Tool instances. It also contains optional instantiation information for one or more IPMP Tool instances. IPMP_Descriptors are conveyed in either initial object descriptors, object descriptors or object descriptor streams via IPMP_DescriptorUpdate commands. An IPMP_Descriptor may also be modified or updated through subsequent IPMP_DescriptorUpdate commands received through the OD stream.

4.4. IPMP Data IPMP Data is the information directed to a given IPMP Tool or terminal to enable, assist or facilitate its operation. IPMP Data includes not only a key but also usage rights, tool initialization information or mutual authentication information. 4.4.1 Places to carry IPMP Data IPMP Data can come from various sources. When it is carried in the content, it can be contained in IPMP_Message class in an IPMP Stream or IPMP_Descriptor. IPMP Data can also be generated by an IPMP Tool or IPMP terminal and delivered to other IPMP Tool or IPMP terminal as a payload of IPMP_MessageFromTool. All IPMP Data are extended from IPMP_Data_BaseClass which is elaborated below.

Each IPMP_Descriptor has an IPMP_ToolID. A zero, “0” value does not correspond to an IPMP Tool but is used to indicate the presence of a URL, otherwise, it describes and signals an IPMP tool protection. The control point where the IPMP Tool works is signaled by another element in IPMP_Descriptor. IPMP_Descriptor also allows carriage of IPMP data extended from IPMP_Data_BaseClass that delivers instantiation, configuration or other information to IPMP Tool instances.

4.4.2 IPMP Data Base Class abstract aligned(8) expandable(2^28-1) class IPMP_Data_BaseClass: bit(8) tag=0 .. 255 { bit(8) Version; bit(32) dataID; }

4.3.2 Signaling with IPMP Descriptor The IPMP_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 IPMP Tool specified in the referring IPMP_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 IPMP Tool specified in the referring IPMP_Descriptor.

Version indicates the version of syntax used in the IPMP Data and shall be set to 0x01. dataID used only when a derived class is carried in an IPMP_ToolMessageBase or IPMP_DeviceMessageBase derived message for the purpose of identifying the message. Tools replying directly to a message shall include the same dataID in any response.

IPMP_DescriptorPointer also has an IPMP_ES_ID that is the ID of an IPMP stream that may carry messages intended for the tool specified in the referred IPMP_Descriptor. In case more than one IPMP stream is needed to feed the IPMP tool, several IPMP_DescriptorPointers can be given with the same IPMP_DescriptorID and different IPMP_ES_ID. If the IPMP_ES_ID is null, it means the IPMP tool does not require any IPMP stream. A value of 2^16-1 for IPMP_ES_ID indicates that this field should be ignored, meaning that the tool pointed to by this IPMP_DescriptorID may receive messages from any IPMP stream within the presentation (following content streams).

Tag indicates the tag for the extended IPMP data. The exact values for the extension tags are not specified in this paper. 4.4.3 Delivery of IPMP Data to IPMP Tools IPMP 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 IPMP Tool whose identity is indicated in the IPMP message or IPMP descriptor header.

By utilizing IPMP_Descriptor and IPMP_DescriptorPointers, the terminal can build an abstract IPMP Control Graph, which bears a tree-like hierarchy. Different IPMP 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.

0-7803-8145-9/04/$17.00 ©2004 IEEE.

Information is delivered at a specific time specified in the bitstream or implicitly delivered by process. IPMP Data carried in IPMP_Descriptor is delivered to the IPMP Tool declared in the descriptor. The IPMP Data is sent as a payload of message IPMP_DescriptorFromBitstream.

428

By the usage of Tool List and IPMP Descriptor, one can easily renew a tool to perform IPMP protection.

IPMP Data carried in IPMP_Message class of IPMP Stream is delivered to the IPMP Tool declared in the IPMP_Descriptor whose IPMP_DescriptorID is indicated in the same IPMP_Message class. The IPMP Data is sent as a payload of message IPMP_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 IPMP Tools.

6. Conclusion This paper introduced a new technology, IPMP (Intellectual Property Management & Protection) for DRM (Digital Rights Management) Renewability and Interoperability. IPMP is proposed to and is standardized as MPEG (Motion Picture coding Expert Group) -2/-4 IPMP. Currently, MPEG-21 Architecture is discussing how to integrate the idea of IPMP and the other existing parts such as DID (Digital Item Declaration), DII (Digital Item Identification), REL (Rights Expression Language), etc. in it. IPMP offers flexibility, robustness and interoperability, which promotes the secure content delivery all over the world. IPMP can be used in combination with proprietary tools, which enables the implementation in various categories, while maintaining the worldwide interoperability.

4.5 Other IPMP messages MPEG-4 IPMP Extension further defines the other messages as follows. All these messages are extended from IPMP_ToolMessageBase. 1) Instantiation and notification messages 2) Event notification messages 3) IPMP processing messages 4) Authentication messages 5) User Interaction messages 6) Consumption permission messages

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.

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.

References 5. Advantages of IPMP architecture

[1] ISO/IEC JTC1/SC29/WG11 MPEG, Text of ISO/IEC 14496-13/FDIS, N5284, (Information technology — Coding of audio-visual objects — Part 13: Intellectual Property Management and Protection (IPMP) extension), Shanghai, Oct 2002. [2] ISO/IEC JTC1/SC29/WG11 MPEG, Text of ISO/IEC 14496-1/PDAM3, N5282, (Amendment to MPEG-4 system on IPMP Extension), Shanghai, Oct 2002. [3] ISO/IEC JTC1/SC29/WG11 MPEG, “MPEG-4 Intellectual Property Management & Protection (IPMP) Overview & Applications”, N2614, Rome, Dec. 1998. [4] ISO/IEC JTC1/SC29/WG11 MPEG, International Standard ISO/IEC 14496-1. 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 IPMP Extension Reference Software Architecture based on IM1, N4850, Fairfax, May, 2002. [6] ISO/IEC JTC1/SC29/WG11 MPEG, ISO/IEC 1381811/FDIS (MPEG-2 IPMP), N5608, Pattaya, Mar, 2003. [7] ISO/IEC JT5C1/SC29/WG11 MPEG, ISO/IEC 138181:2000/FDAM2 (MPEG-2 IPMP Amendment), N5604, Pattaya, Mar, 2003. [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, 2001. [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 2003

The proposed IPMP architecture fulfils the following requirements: Flexibility: One can choose whatever algorithms to perform decryption, watermarking, user authentication or integrity checking. Dynamic operation: Various IPMP Tool protection can be signaled in the content with the help of IPMP 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 IPMP messages. Interoperability: By using a common set of IPMP messages, industry defined messaging API and message extension, different IPMP Tools can be easily plugged into the terminal and interact with each other. Renewability:

0-7803-8145-9/04/$17.00 ©2004 IEEE.

429