From OPIMA to MPEG IPMP-X: A standard's history across R&D projects

ARTICLE IN PRESS

0923-5965/$ - se

doi:10.1016/j.im

�Correspondi

E-mail addr

[email protected]

URL: http:/1Panos Kudu

Middlesex, UB32MPEG IPM

Signal Processing: Image Communication 20 (2005) 972–994

From OPIMA to MPEG IPMP-X: A standard’s historyacross R&D projects

Carlos Serraoa,�, Jose Miguel Salles Diasa, Panos Kudumakisb,1

aADETTI/ISCTE, Associac- ao para o Desenvolvimento das Telecomunicac- oes e Tecnicas de Informatica, Edifıcio ISCTE,

1600-082 Lisboa, PortugalbinAccess Networks S.A., 95A Pentelis Av., GR 152 34 Halandri, Athens, Greece

Received 4 October 2004; accepted 24 April 2005

Abstract

This paper describes the work performed by a number of companies and universities who have been working as a

consortium under the umbrella of the European Union Framework Programme 5 (FP5), Information Society

Technologies (IST) research program, in order to provide a set of Digital Rights Management (DRM) technologies and

architectures, aiming at helping to reduce the copyright circumvention risks, that have been threatening the music and

film industries in their transition from the ‘‘analogue’’ to ‘‘digital’’ age. The paper starts by addressing some of the

earlier standardization efforts in the DRM arena, namely, Open Platform Initiative for Multimedia Access (OPIMA).

One of the described FP5 IST projects, Open Components for Controlled Access to Multimedia Material (OCCAMM),

has developed the OPIMA vision. The paper addresses also the Motion Pictures Expert Group—MPEG DRM work,

starting from the MPEG Intellectual Propriety Management and Protection—IPMP ‘‘Hooks’’, towards the MPEG

IPMP Extensions, which has originated the first DRM-related standard (MPEG-4 Part 13, called IPMP Extensions or

IPMP-X) ever released by ISO up to the present days.2 The paper clarifies how the FP5 IST project MPEG Open

Security for Embedded Systems (MOSES), has extended the OPIMA interfaces and architecture to achieve compliance

with the MPEG IPMP-X standard, and how it has contributed to the achievement of ‘‘consensus’’ and to the

specification, implementation (Reference Software) and validation (Conformance Testing) of the MPEG IPMP-X

standard.

r 2005 Elsevier B.V. All rights reserved.

Keywords: Copy-Protection; OPIMA; OCCAMM; MOSES; Digital music; Rights; Intellectual Property Protection

e front matter r 2005 Elsevier B.V. All rights reserved.

age.2005.04.005

ng author.

esses: [email protected], [email protected] (C. Serrao), [email protected] (J.M.S. Dias),

(P. Kudumakis).

/www.adetti.pt.

makis from 1998 to 2004 was with Scipher-Central Research Laboratories (former EMI), Dawley Road, Hayes,

1HH, UK.

P-X was released in 2003 and is currently the single ISO standard in the DRM arena.

ARTICLE IN PRESS

C. Serrao et al. / Signal Processing: Image Communication 20 (2005) 972–994 973

1. Introduction

While digital technology has enabled new andmore flexible means to create, exchange, store andconsume multimedia content, when compared tothe ‘‘analogue era’’, it has eliminated many of thebarriers which have been implicitly granting valueto the content, allowing, e.g. an easy sharing ofdigital material over networks with no loss ofquality even after an unlimited number of copies.In this context, the modern content distributionbusiness models such as the Internet downloadand super-distribution (through Peer to Peer—P2Pnetworks), have proven to have considerable flawsand drawbacks. This has led to the need ofreassessing and modifying, traditional approachesof content protection. This change in the valuechain has affected mostly the music and filmindustries. Mass storage and copy systems havebecome cheaper, Internet bandwidth at the finaluser home has increased, as prices for maintainingit have fallen, and the content compressiontechnologies have evolved in such a way, that ithas created an increased interest for potentialillegal use.

Currently, the content industry is trying toidentify illegal copiers who are using file sharingsystems. Internet providers are forced by court toopen their user logs and allow externals toprosecute their illegal users. On the one hand,the principle of anonymity and the protection ofpersonal information have become highly ques-tionable. On the other hand, this approach willhave difficulty in coping with the complete numberof illegal distributions, since the number of usersthat are taking part in these systems (in the orderof millions and growing on a daily basis [16,17])are diminishing the probability of being caughtand consequently the prevention of illegal mediadistribution. Other approaches must be found.These can only work by controlling either thedistribution of the content via trusted channels orthe protection of the content with access control,or the combination of both.

This paper provides both an overview of thedevelopment of new standards (from ISO andother bodies) and technologies which deploy acomprehensive framework for dealing with digital

copyright protection and intellectual proprietyrights as well as the description and achievedresults of two EU Information Society Technolo-gies (IST) RTD projects (Open Components forControlled Access to Multimedia Material (OC-CAMM) [45] and MPEG Open Security forEmbedded Systems (MOSES) [41]), that haveaddressed the implementation, benchmark andevaluation of such technologies and standards.This set of Digital Rights Management (DRM)technologies are currently enjoying world-widesupport not only because they have been approvedas International Standards (ISO/IEC JTC1/SC 29/WG11 14496-13 (MPEG-4) [27] and 13818-11MPEG (MPEG-2) [20]), but also due to the factthat they provide the means for achieving inter-operability among different manufacturers ofdevices, independently of the way that content isprotected. The paper is organized as follows: First,a definition of DRM is given, which has theagreement of the Networked Audio–Visual Sys-tems and Home Platforms projects of the SixthFramework Programme of the European Union.Afterwards, the OPIMA initiative [48] is intro-duced, where most of the concepts currentlysupported by the Intellectual Propriety Manage-ment and Protection (IPMP)-X standard wereoriginated. The IST project OCCAMM, whichimplemented for the first time the OPIMA vision,is then described, focusing in the developedarchitecture and achieved results. The MPEGcommunity own efforts of creating a DRM-relatedstandard are then introduced, starting from theIPMP ‘‘Hooks’’, that evolved into the currentMPEG IPMP-X ISO standard, which is alsodescribed in a concise way. The FrameworkProgramme 5 (FP5) MOSES RTD project is thenintroduced, since it aimed at extending theOPIMA implementation (from IST OCCAMM)to achieve compliance with MPEG IPMP-X and,at the same time, to contribute to the developmentof this ISO standard. This was achieved withsuccess and two of the technological results, thathave integrated with the MOSES MPEG IPMP-Ximplementation, are then described, namely theopen-source DRM platform, referred to asOpenSDRM—Open Secure Digital Rights Man-agement and Music-4You, a digital music B2C

ARTICLE IN PRESS

C. Serrao et al. / Signal Processing: Image Communication 20 (2005) 972–994974

e-commerce site, which were developed to provethe technological concepts behind MOSES,namely, the MPEG-4 IPMP-X implementationintegrated into the OpenSDRM platform integra-tion.

2. A definition of DRM

A precise definition of DRM, from the technicaland economical point of views, can be found in [1]:‘‘DRM systems are means of assigning access todigital contents. In other words, DRMs are, firstof all, technological tools designed for excludingconsumers from information goods, which, other-wise, would be public goods. In that function, theysupplement intellectual property rights whoseeconomic role is to provide incentives in intellec-tual creation by giving the owner a temporarymonopoly on exploitation. This is why DRMsfrequently refer to rights models as to define therange of accesses they grant. By doing so, DRMsshould also be considered as versioning tools,providing to each kind of content, a pre-defined setof utilities that grant liberality of content use: rightto view (hear), modify, record, excerpt, translate inanother language, keep for a certain period, copy,distribute, etc.’’. DRM systems, which are in facttechnical private measures protecting copyright,enforce a contractual agreement between parties(e.g. content owners and end-users or subscribers),that fix the width of their rights and that cansometimes override copyright law and especiallylimitations to copyright law as fair uses.3

OPIMA VirtualMachine

ApplicationServices

API

ApplicationServices

IPMP#1

IPMP#2

IPMP#n

IPMPServicesAPI

3. The OPIMA initiative

Open Platform Initiative for Multimedia Access(OPIMA), an initiative of the Industry TechnicalAgreement (ITA) program of the InternationalElectrotechnical Commission (IEC), was estab-lished4 with the purpose of enabling a framework

3By fair use (a concept valid in the United States and defined

in the US 1976 Copyright Act, S 107), we refer to cases such as

time shifting, private backup copying or uses for educational

purposes.4OPIMA had its kick-off meeting in Turin in March 1998.

[48] where, content and service providers, wouldhave the ability to extend the reach of theirprospective customers and, consumers, wouldhave the ability to access a wide variety of contentand service providers in a context of multiplecontent protection systems.

The OPIMA specification included its architec-ture and a description of the functions required toimplement an OPIMA-compliant system. Further-more, it included also security protocols and adescription of Application Programming Inter-faces (APIs) and functional behaviours thatenabled interoperability (Fig. 1).

The OPIMA specification was device andcontent independent. Content was perceived toinclude all multimedia types and executables.OPIMA introduced the Rules concept, referredto information that stipulates how content may beused on a given device; specifically, Rules deter-mined how business models should be established.OPIMA also created the concept of IntellectualProperty Management and Protection (IPMP). AnIPMP system controls access and use of thecontent by enforcing the rules associated with it(Fig. 1). Conditional access systems were consid-ered as particular examples of IPMP systems. Inthe Optima’s vision, protected content consisted ofthe following:

�
A content set, which may be composed ofdifferent multiple media types;
�
An IPMP system set, which may consist ofmultiple IPMP systems;
�
A set of rules that could be applied under thegiven IPMP system.
OVM

Native Hw & Sw

Fig. 1. The OPIMA architecture.

ARTICLE IN PRESS


OPIMA has finished its work in June 2000, byreleasing version 1.1 of its specification [48]. In thisspecification, OPIMA defined the need for somebuilding blocks such as the OPIMA VirtualMachine (OVM) and the IPMP systems (Fig. 1),as well as it recognized the need for back-endinfrastructure and a set of trusted institutions(capable of credential issuance), but it did notspecify how this back-end or institutions would haveto be developed, how they have to work and howthey interrelate with each other. The only normativepart specified by OPIMA was the ApplicationServices API and the IPMP Services API. Anothernormative part of OPIMA is the protocol definitionneeded for the establishment of Secure Authenti-cated Channels (SACs) among OPIMA peers. Oneof the major components of OPIMA is the OVM.The OVM can be seen as a closed black box thatreceives protected content and renders it. The onlyexternal communication points are service APIs.

4. Implementing the OPIMA vision

After the release of the OPIMA specification,the most active contributing organizations of theOPIMA initiative joined together and submittedan RTD project proposal to the IST programme inthe EU FP5 framework. This proposal was namedOpen Components for Access to MultimediaMaterial (OCCAMM) and one of the mostambitious goals of it, was the implementation ofthe OPIMA vision and its specifications. Thisproject was approved and started on January 2000with the following objectives:

�
The specification and development of a series ofenabling tools and components, which werecompatible with emerging standards and re-commendations (MPEG, OPIMA, Secure Di-gital Music Initiative—SDMI), which wouldhandle the controlled access, delivery, con-sumption, rights management and payment ofmultimedia content.
�
The establishment of a number of commerciallydriven applications that used the aforemen-tioned tools, which would deliver the needs ofall participants in the project.
�
The definition and monitoring of performancelevels in trial environments for such applica-tions, pointing out additional actions neededfor subsequent full and successful commercialexploitation.
OCCAMM targeted specific innovative devel-opments in the most diverse areas:

�
Open, secure user environment based on theOVM concept and its implementation on ageneral-purpose PC platform;
�
Encryption and scrambling, key managementand authentication techniques assembled toconstitute complete IPMP systems in confor-mance to OPIMA and MPEG-4 specifications,with the capability of automatically trackingcontent usage as well as usage of copyrightedcontent processing technologies;
�
Watermarking technologies targeted to theaudio and video domain of application inmonitoring, copy/access control and finger-printing, conformant with MPEG-4, OPIMAand SDMI requirements;
�
Copy Protection (CP) techniques; � Content metadata insertion and processing
tools.

The other two components in the OPIMAPlatform, implemented by OCCAMM, were twoAPIs: the Application Services API and IPMPServices API:

1.
The Application Services API intended to beused by applications, which normally havesome user interface. With this API, nowavailable, upon user request, an Applicationcan call a set of API methods to: query theOVM, download a given IPMPS System (whichwill be executed by the OVM), send messages tothe IPMPS and send the OVM instructions forContent usage. The Application Services API isimplemented by the OPIMA platform andprovides the sole entry points to an Application.Based on the answer from the OVM, theApplication can ask the User to select apreviously downloaded IPMPS, or ask theOVM to download, install and run a new

ARTICLE IN PRESS


content-specified IPMPS. Apart from the API,nothing else is specified by OPIMA for theApplication, which can have any type of UserInterface (e.g. Internet browser, TV remotecontrol).

2.
The IPMP Services API intended to be used byIPMPS. This currently available API provides aset of methods that allow the IPMPS to: requestContent Rules and/or User Rules, access to theOVM encryption/decryption, signature andwatermarking engines, access to smart-cardinterfaces, communication with the user (di-rectly), with the application, and with remoteIPMPS. Content is handled only by the OVM;however, it is the IPMP system that takesthe decision if a User is entitled to perform theaction requested. This decision is taken by theproprietary code in the IPMPS based onContent Rules and User Rights. If affirmative,the IPMPS will provide the OVM with the keys,or the means to obtain them, that will allowdecrypting the Content. At a given time, severalIPMPS may be running in the multitaskingenvironment managed by the OVM.
OCCAMM endorsed the complex task ofimplementing the first set of PC OVMs, theexternal API interfaces, the necessary IPMP tools,demonstration applications and the neededsupport infrastructure. This was achieved withsuccess.

4.1. OCCAMM main results

One of the most impressive results of theOCCAMM project was the implementation ofthe OVM. As it was referred previously, the OVMacted as a black box that had the necessarycapabilities and mechanisms to render protectedcontent. Once closed, this box could only commu-nicate with the outside world via the services(Application and IPMP) APIs. One of the optionsmade by the OCCAMM project was the type ofcontent that the OVM was capable of rendering.The choice resided in MPEG-4 content—Advanced Audio Coding (AAC) Low-ComplexityProfile audio files [28] with Advanced SimpleProfile (Levels L4 & L5) video files [29], including

JPEG still pictures, all wrapped in MPEG-4 FileFormat [29]. OCCAMM’s OVM implementationreceived protected MPEG-4 content from externalsources and was capable of rendering suchcontent. The following picture (Fig. 2) depictsthe OCCAMM implementation of an OVM.OCCAMM defined its implementation based onthe OPIMA specifications and on the analysiswork carried by the project.

Some of the most important components of theOVM implementation were (Fig. 2):

�
Scheduler: this component was responsible formanaging all the OVM operations, assuringthat these were executed as they were supposedto be;
�
SAC: this component was used to establishsecure and authenticated channels with otherOPIMA peers (using the Secure Sockets Layer(SSL) protocol). The SAC was used for down-loading IPMP tools and user licenses;
�
IPMP System manager: managing the IPMPsystems that were present on the system was oneof the main goals of this component;
�
Content Registry: this component was in chargeof registering the content on the OVM;
�
IPMP services: this component provided all theservices indicated by the OPIMA specificationto the IPMP systems;
�
Application services: this component providedall the services indicated by the OPIMAspecification to the Applications;
�
MPEG-4 player: this component was respon-sible for decoding and rendering the MPEG-4content;
�
Protection tools: the encryption and/or water-marking algorithms that were used to eitherdecipher or fingerprint the content were directlyimplemented on the OVM. On the OVM therewas not the possibility to renew the protectiontools.
Apart from the OVM implementation, OC-CAMM also implemented two different IPMPsystems, one smartcard-based and the othersoftware-based. Also, a set of generic externalelements that composed the supporting infra-structure were also developed: a License Server

ARTICLE IN PRESS

OVM Core IPMP Services

MPEG-4 Player Core

Applications

Engine Interfaces

OVM

Listener

Scheduler

OVMConfiguration

SAC IPMPManager

Comm. Interfaces

from

contentsource

communicate

control

ElementaryStreamController

instantiate

to/fromotherpeers

IPMPS

Listeners

communicate

communicate

controlregister

control

to

contentrenderer

Protectiontools(local)

Protectiontools(stream)

Fig. 2. OCCAMM’s OVM architecture.


(LIS), an IPMP systems server and a CertificationAuthority. These latter components were sug-gested by the OPIMA specification but notspecified. The LIS is the component that isresponsible for issuing the licenses for contentusage. The Certification Authority is used to issuethe cryptographic credentials for the OPIMApeers, needed for the establishment of secure andauthenticated channels between them. The IPMPsystems server is the entity that supplies the neededIPMP systems to the OPIMA peers that need themto process the content. Additionally, for each ofthe trials performed within OCCAMM, a ContentPreparation server (CPS) and an e-commerceplatform were also developed.

4.2. OCCAMM tests and trials

The OCCAMM project consortium developed aseries of trials in order to validate the OPIMAarchitecture. One of these trials was focused on thecommercialization of protected digital music overan Electronic Commerce web-site and on control-ling the access of such music content on the clientplatform.

OCCAMM provided a new mechanism forselling and distributing digital music recordingsto consumers. This system combined the latestdigital distribution technology, with developmentsin Internet multicasting, e-commerce and intellec-tual property management. The OCCAMM

ARTICLE IN PRESS


platform comprised five main components (Fig. 3).These components were identified by OCCAMMas the necessary components to implement itsbusiness model and trials. The trials included thesecure production, distribution and consumptionof content along the value chain. The fivecomponents are as follows:

�
The Electronic Commerce Platform (ECP)
where orders for music products could be placed:It contained a full catalogue of all products forsale and enabled registered users to selectproducts for distribution and authorize pay-ment (note that payment facilities were depen-dent of the transaction model(s) deployed).Payment facilities included credit card payment,subscription management, micropayment andpay-per-view. The ECP also managed distribu-tion scheduling for all products.

�
The OCCAMM Service Centre contained all of
the content available through OCCAMM in

digital form: This centre also hosted the multi-casting software required to distribute contentto the users. The centre was located at theground station of the satellite service providerused during the project. This removed the need

Ethernet

Router

OCCAMM ARCHITEC

Et

Router

Internet

MultimediaServer Backup

Production Station

OCCAMM SERVICECENTRE

PRODUCTION STATION

MultimediaServer

OCCAMMLicense

Server Backup

OCCAMMLicense Server Satellite Se

Provider D

ProductionStation Backup

Payment Gateway

PAYMENT GATEWAY

Fig. 3. OCCAMM trials

for a high bandwidth link between this servicecentre and the ground station in order todistribute products following a user order.Instead, the centre was installed on the groundstation LAN, facilitating rapid and economicaldelivery of the requested products via thesatellite up-link facilities. Streaming softwarewas also hosted on the OCCAMM ServiceCentre, which provided streaming services tousers. The services provided by OCCAMMwere not limited to satellite delivery. It wasenvisaged that alternative distribution mechan-isms would be also implemented, e.g. in ADSLand standard Internet distribution.

�
A Client PC: Users wishing to use theOCCAMM service required a Client PC. Thisterminal facilitated the ordering, reception,management and consumption of digital con-tent available via OCCAMM. Each consumerterminal required hardware (i.e. smart cardreader) and software capable of performing theabove functions. The OVM formed the core ofthe OCCAMM Client PC. Installed on theClient PC OVM were the IPMP Systems(IPMPS). The Content offered and distributedvia the OCCAMM service was encrypted by an
Ethernet

Router

Web SiteFront End Backup

DatabaseServer

TURE OVERVIEW

End User's PC

Modem

CD Writer

CLIENT PC

E-COMMERCE PLATFORM

Satellite

rviceish

Home satellitedish

Web SiteFront End

DatabaseServer Backup

ADSL ModemADSL

architecture.

ARTICLE IN PRESS


IPMPS. The IPMPS consisted of the server part(IPMPS LIS) and the client part. The serverpart was responsible for the creation, manage-ment and distribution of the licenses to theClient PCs. The Client part resided on theClient PC, which communicated with theIPMPS LIS via the OVM. All communicationswith the IPMPS (client and server parts) weresecured using the OPIMA SAC.

�
Production Station: This station consisted of aset of utilities, which prepared the content fordistribution and use. These utilities included awatermarking encoder, an encryption systemand an MPEG-4 audio/video encoder. Allcontent prepared by the Production Stationwas transferred to the Multimedia ServerContent Store via FTP (either standard internetconnection, ISDN or Leased Line) for subse-quent distribution to users. The music wasencoded using AAC Low-Complexity Profile[29] in MP4 File Format [49] which contained ascene composed by the music track and a JPEGimage of the artist/album from which the musicwas originated. Therefore when the user openedthe music track on the player, it also viewed theimage. Some video clips were also availableencoded in Advanced Simple Profile, L4 and L5Levels [28,49].
�

5The OPIMA specification v1.0 was published in 1999, while

the second and final version v1.1 of the specification was

published in 2000.

Payment Gateway (PGW): This provided theOCCAMM system with the means to processpayments for content purchased by users. Forthe purpose of the OCCAMM project, a PGWconstituted either a bank/financial institutionproviding Electronic Commerce facilities, aTrusted Third Party providing payment servicesor a Micropayment system capable of proces-sing transactions of small value. Any commu-nication between the E-Commerce Platform anda PGW was secured via an SSL connection. Thisensured any financial information being trans-ferred between the two entities remained secure.

5. MPEG IPMP

This section describes the standardization work,carried under the MPEG auspices related to

DRM. It starts by describing the initial effortscarried by MPEG, referred to as MPEG IPMP‘‘Hooks’’ [23]. The section then presents thedefinition of the new standard, MPEG IPMPeXtensions [25,27], an evolution from MPEGIPMP ‘‘Hooks’’, which shows a much higher levelof interoperability than the ‘‘Hooks’’ specificationin terms of both protection tools and businessmodels.

5.1. MPEG IPMP ‘‘hooks’’

Meanwhile, almost at the same time thatOPIMA released its first version of the specifica-tions,5 the MPEG finalized its work on the IPMP‘‘Hooks’’ [23,24,26].

In the IPMP ‘‘hooks’’, a set of points in thedecoding chain called Control Points were norma-tively defined; in each of them, a protectionmechanism (called IPMP Systems) could beplugged in, to perform IPMP processing on themedia data flowing from the decoding buffer downto the renderer (Fig. 4). The time-varying informa-tion such as decryption keys, sync info, etc. couldbe delivered to the IPMP System through adedicated stream called IPMP Stream [36].

The ‘‘IPMP hooks’’ provided the IntellectualProperty Identification Data Set (IPIDS). ThisIPIDS could be used to associate various contentidentifiers with the audio–visual objects (AVO)contained in an MPEG-4 bit stream. The associa-tion of an IPIDS with AVO was accomplishedthrough its addition into the AVO elementarystream descriptor. The MPEG-4 IPMP providedthe ‘‘IPMP hooks’’ themselves which allowedproprietary DRM systems to be used within anMPEG-4-compliant terminal by associating the IDof an IPMP system with each AVO [36]. Theuniqueness of this identifier was regulated by aregistration authority. This identifier indicatedwhich IPMP system governed the AVO. Inaddition to the IPMP system ID, MPEG-4 IPMPprovided space for ‘‘private’’ data that IPMPsystems could use to transmit any data they would

ARTICLE IN PRESS

Fig. 4. MPEG-4 ‘‘IPMP hooks’’ architecture.


need for its operation. The IPMP system ID andthe private data for the IPMP system could beassociated with the AVO using the same mechan-ism used for linking the IPIDS to the AVO.

The specification provided a second mechanismfor associating IPMP system IDs and privateIPMP data with AVO: adding an IPMP elemen-tary stream into the bit stream allowing thesynchronization of IPMP data with AVO. Thiswas useful when using MPEG-4 streaming whereIPMP information needed to be repeatedly sent toallow devices to start receiving and decodingcontent from arbitrary points within the bitstream. This mechanism also enabled a serviceprovider to regularly change keys to the content,providing additional security levels [36].

IPMP ‘‘hooks’’ allowed several IPMP systemsto co-exist on the same Terminal. According to thechosen protected content, the IPMP Systemspecified by the Content Owner at authoring time

would be instantiated. The IPMP System itself wasproprietary. However, the following issues wereleft open by IPMP ‘‘hooks’’:

�
There was no standard way to specify how anIPMP System can be ‘‘hooked’’ in a MPEG-4player without previous agreement betweenMPEG-4 player manufacturers and IPMPSystem providers;
�
There was no standard mechanism to allowIPMP Systems to authenticate each other;
�
There was not easy provision to replace a‘‘broken’’ IPMP system.
The MPEG-4 IPMP-eXtensions [25,27], whichare described next, were designed to answer theabove ‘‘open questions’’ and to provide a morecomplete DRM architecture within MPEG and todo so in a secure manner.

ARTICLE IN PRESS


5.2. MPEG IPMP extensions

MPEG, recognizing the value of content bothfor content owners and users, has been active since1998 in defining standard solutions in the DRMarena to regulate the access to MPEG content. Asa result of this activity, MPEG has recentlydeveloped the IPMP eXtensions (IPMP-X) speci-fication [25,27], which has been one of the lastavailable DRM solutions to govern MPEG con-tent throughout its life, providing a secure frame-work that can host any number of proprietaryprotection algorithms thus granting interoperabil-ity in respect of allowing end users to get contentfrom different service providers protected withdifferent DRM systems.

The MPEG IPMP eXtensions do not ‘‘break’’or otherwise negatively impact existing implemen-tations based on the original ‘‘Hooks’’ specifica-tions [25,30,31]. An identifier is defined in order tospecify which IPMP solution is being used.MPEG-4 IPMP ‘‘Hooks’’ protected content maybe accessed by a MPEG-4 IPMP-X terminal.

CONTENTSTREAM DMIF

DE

MU

X

AUDIODB

VIDEODB

CDDB

BIFSDB

IPMPDB

IPMP TOOLS LIST/TOOLS ES

TOOL MANAGER INTERFAC

OBTAIN MISSINGTOOLS

MISSINGTOOLS

MPEG-4CONTENTSTREAM(s)

IPMPCONTENTSTREAM(s)

IOD

PMPMESSAGE

TOOL LIST

TOOL D

ALTERNATETOOLS(s)

PARAMETRICDESCRIPTION(s)

TOOLD ESC

CONTENTREQUEST

CONTENTDELIVERY

Fig. 5. MPEG-4 IPMP Ex

MPEG-4 IPMP-X protected content will beconceived by an IPMP ‘‘Hooks’’ terminal as beingprotected by an unknown IPMP system [25].

The MPEG IPMP eXtensions is delivered in twoflavours: MPEG-2 IPMP-X (Part 11) [19,20] andMPEG-4 IPMP-X (Part 13) [25,27]. MPEG-2IPMP-X [20] is designed to be applied to MPEG-2 based Systems [19]; MPEG-4 IPMP-X [27]is designed to be applied to MPEG-4 basedSystems [25].

MPEG-4 IPMP-X (Figs. 5 and 6) can be used tohost any type of media protection at a varied levelof granularity and complexity, as required by thespecific DRM system employed to protect a givencontent within MPEG-4 Systems. MPEG-4 IPMP-X may protect any kind of media content includedin an MPEG-4 stream, as e.g. video, audio,computer graphics, text, interactive contents, etc.

MPEG-2 IPMP-X [20] is provided in MPEG-2Systems [19] with the same functionality andsupport as in MPEG-4 IPMP-X [25,27]. MPEG-2 IPMP-X may protect any kind of content thatcan be inserted in an MPEG-2 transport stream, as

AUDIOCB

CO

MP

OS

ITE

R

RE

ND

ER

ER

AUDIODECODE

VIDEOCB

VIDEODECODE

CDDECODE

BIFSCB

BIFS TREES\SCENEGRAPH

TERMINALIPMP MESSAGE ROUTER / TOOL MANAGER

BIFSDECODE

PMPDESC

E MESSAGE ROUTER INTERFACE

IPMPTOOLS A

IPMPTOOLS B

IPMPTOOLS C

IPM

PT

OO

LS M

ES

SA

GE

tensions architecture.

ARTICLE IN PRESS

Fig. 6. MOSES MPEG-4 IPMP-X implementation architecture.


e.g. video, audio, text, private streams, etc. IPMP-X can also be integrated in other non-MPEGbased Systems easily, as long as these systemsprovide the appropriate integration APIs similarto MPEG IPMP ‘‘hooks’’. Nevertheless, this issomething that the most popular media players(such as Windows Media Player, Apple iPod andother) do not yet support trying to monopolize themarket by locking consumers and even govern-ments into their proprietary DRM systems andtrying to create ‘‘de facto’’ standards.

In 1997, MPEG issued a Call for Proposals fortechnology in the area of IPMP. After receivingthe proposals and the ensuing discussions, MPEGand the experts drawn to MPEG by the Calldecided, in 1998, that it would not be appropriateto standardize complete systems, but that justproviding the right interfaces (or hooks) would bewhere standardization should stop. At that time itwas believed that only a few IPMP Systems wouldemerge in the market, thus interoperability amongthem could take place using the ‘‘hooks’’ andcomplemented by bi-lateral agreements signedamong the different IPMP System providers and

players’ manufacturers. In 1998 and 1999, IPMPtechnology has matured, requirements for thesesystems have become clearer, and also MPEG’sunderstanding of the role of IPMP technologies inbuilding interoperable devices and services hasevolved. Also, it became clear that not all partiesrepresented in MPEG were convinced that onlyproviding the interfaces would be enough. Parti-cularly, some parties were concerned about inter-operability between different products, often forsimilar services, as developed within the IPMPframework of the MPEG-4 Standard. Also, withconvergence becoming a reality, e.g. through thedeployment of broadband Internet access andthe start of new services on mobile channels,interworking between different types of devicesand services becomes a more important require-ment. It was the belief of these parties, that theexisting MPEG-4 IPMP ‘‘hooks’’ Framework—with its demand for bi-lateral agreements amongIPMP System providers and players’ manufac-turers—did not provide the necessary infrastruc-ture to meet their interoperability requirements. Itis MPEG policy to support legitimate requests to

ARTICLE IN PRESS


standardize on a technology, knowing that thosenot interested in that particular standard technol-ogy have no obligation to adhere to it because ofconformance obligations [42].

In the eXtensions, a more mature level oftechnology and a clearer understanding of the roleof IPMP technologies made the MPEG group comeout with a solution which does not need bi-lateralagreements, granting far much more interoperabil-ity between different IPMP modules (called IPMPTools) [27], by defining a message-based interfacesupporting the co-existence and communicationbetween any pair of IPMP Tools and between themand the MPEG-4 player (Figs. 5 and 6). Usingnormative messages, IPMP Tools can interchangeany kind of information, including mutual authen-tication data, in order to ensure that the plugged-insare the ones they claim to be and not ‘‘malicious’’,thus granting a secure operating environment [27].

When users request access to IPMP-X protectedcontent, the MPEG-4 terminal processes the IPMPTool List (Fig. 5), a structure which specifies theIPMP Tools meant to govern the access to thecontent [27]. These are then located, (if not presentlocally can be downloaded from a supplied loca-tion), and instantiated by a conceptual entity withinthe Terminal: the Tool Manager (TM). Anotherconceptual entity, the Message Router (MR), takescare of routing information between Tools andterminal. This communication takes place by meansof normative and user-defined messages (Fig. 6). Ifmutual authentication succeeds, and all the condi-tions the IPMP Tools require are fulfilled, a RightsManagement IPMP Tool checks the validity of thelicense associated to the content, and then proces-sing of the individual elementary streams starts. Asan example, a decryption Tool decrypts the contentand sends it to the media decoder for that particularcontent. Then the media decoder decompresses thestream and passes it on to a watermarking Tool,which reads or writes the payload from/into thecontent and finally, passes it on to the rendererwhich will present it to the user (Fig. 5).

Communication between the IPMP-X frame-work and IPMP Tools, or between any pairof IPMP Tools, is based upon a messagingframework (Fig. 6). The specification defines aset of normative messages, which the IPMP Tools

need to generate and send or interpret uponreceipt, in order to be able to communicate withthe other entities in the framework. These can begrouped in the following categories [27]:

�
IPMP Tool Connection and Disconnection Mes-
sages: Used to instantiate and destroy logicalinstances of new Tools, and to allow Tools tofind out information about other Tools;

�
Event Notification Messages: To provide theIPMP Tools the ability to request and getnotified of events such as connection ordisconnection of other Tools, watermark detec-tion, etc;
�
IPMP Processing: Defined to be used in theIPMP process covering a wide range ofscenarios, like conveying keys, usage rules, tocommunicate with an audio or video water-marking Tool, to configure selective encryption,and so on;
�
Authentication Messages: Defined to verify thetrust relationships existing between two entities(Tools or Terminal), and to determine or createsecure channels of communication as needed,based on the application;
�
User Interaction Messages: To allow informa-tion to be exchanged between the user and anentity requiring information from the User;
�
Consumption Messages: To allow an IPMPTool to notify the terminal about its consensusto process content or not;
In summary, the key advantages brought byIPMP eXtensions can be summarized as thefollowing [39]:

�
Interoperability: Thanks to the set of normativemessages, interaction between different IPMPTools is allowed;
�
Security: Normative mutual authenticationnegotiation mechanisms are provided to ensurea secure operating environment;
�
Flexibility: Free choice in choosing the algo-rithms (mutual authentication, protection suchas encryption and watermarking, management,etc.) to govern the content;
�
Renewability: Easy replacement of weak or oldIPMP Tools.

ARTICLE IN PRESS


IPMP-X, has finalized its specification in Octo-ber 2003 [19,20,25,27], and its reference software
[22,31] and conformance testing suite [21,30] wereready by March 2004 [22,30,31]. Currently it isbeing already adopted and supported by anincreasing number of companies [15] and con-sortiums [18,34], all over the world. The coretechnology of IPMP-X (MR and TM) is alsounder discussion and consideration for adoptionby MPEG-21 IPMP Components [54], DigitalMedia Project—DMP [4,7], DVB TM-SEC andAudio–Video Coding Standard Group of China—AVS China. The key benefits brought to contentowners, end users and industry, are believed to beable to revolutionize the whole experience ofaccess to protected content.
6. MOSES and the IPMP-X framework

MOSES was the natural evolution of the workalready achieved in the IST OCCAMM project.Most of the organizations present in the MOSESproject had already participated in the ISTOCCAMM project. One of the MOSES goalswas to extend the OPIMA interfaces and archi-tecture to achieve compliance with the emergingsecurity standards such as MPEG IPMP-X, help-ing to consolidate the integration of research andconcertation of the projects in the field ofNetworked Audiovisual systems and Home Plat-forms and to develop visions and recommenda-tions so as to foster consensus among the variousstakeholders (broadcasters, telecom operators,content and service providers, research and aca-demic and users at large) on future industrial andresearch initiatives. Another aim of MOSES was

Table 1

Comparing OPIMA and MPEG IPMP-X

Features OPIMA

Ability to download Rules/licenses and polic

Secure environment based on Tamper resistance/OPIM

Targeting applications STB and mobile devices

to contribute to the specification [19,20,25,27],implementation (Reference Software) [22,31] andvalidation (Conformance Testing) [21,30] of theMPEG-2/4 IPMP-X concepts. The ReferenceSoftware and Conformance Library were devel-oped in close collaboration between MOSES andPanasonic Singapore [2,40].

The OCCAMM extension, through the MOSESproject took place in three axes (download ability,secure environment and target applications) as canbe seen in Table 1. This extension resulted in theMPEG-4 reference implementation of IPMP-Xand is included in the MPEG-4 reference code [2].

The OPIMA solution was the first to recognizethe need to make content access rules (licenses)as much portable as possible but did not recognizethe need of downloading protection componentsinto the terminal, since this was based onthe assumption that only a few would emerge as‘‘de facto’’ standards and thus, it would bepossible to accommodate them in an OPIMA‘‘compartment’’ achieving interoperability. An-other reason with respect to the latter issue wasthe consideration that the most security-sensitivecomponents were not the protection algorithmsthemselves but the key management mechanisms.Thus, OPIMA also adopted the operation in atamper resistance environment, assuming an en-vironment capable of resistance against internalor external modifications by third parties, neverallowing clear text content to be exposed outsideof it.

Different from OPIMA, MPEG IPMP Exten-sions was designed not only to be able to down-load protection components into the terminal, butto perform it in a secure way as well. This has beenachieved by introducing Mutual Authentication

MPEG IPMP-X

y Rules/licenses, policy and protection

algorithms (encryption, WM, etc.)

A compartment Mutual authentication allowing tools to

be linked together

Military, government, D-cinema to STBs

and mobile devices

ARTICLE IN PRESS


negotiation mechanisms in the standard, allowingdifferent protection components from competingvendors to co-work and interoperate. By notrelying any more in tamper resistance environ-ments, MPEG IPMP-X has also increased thenumber of application domains where the stan-dard can be used, which has been also in line withthe diverse range of applications that MPEGcovers.

Due to the aforementioned reasons, the MOSESgoal of extending the OPIMA vision to MPEGIPMP-X has been achieved in such a way that hasnot invalidated OPIMA, and can be seen as aconceptual profile of MPEG IPMP-X suitable forlimited resources (portable) devices.

Comprehensively the main goals of IST MOSEScan be synthesized in the following:

�
Extension of the OPIMA interfaces and archi-tecture to achieve compliance with the mostrecent ISO security standards;
�
Extension of current business models to en-compass operational scenarios where the full setof functionalities pertaining to IPMP systemshave been implemented and tested;
�

6ISO/IEC JTC 1/SC 29/WG 11—MPEG-21 has issued a Call

for Proposals in March 2004 ‘‘Requirements for MPEG-21

IPMP’’. Answers to the call were submitted [13] and the work

on this new standard is on going. The standard is in Committee

Draft stage, at the time of writing of this paper.

Porting the end-to-end MPEG-4 IPMP-Xcompliant secure infrastructure to devices otherthan the PC, addressing typical ConsumerElectronic (CE) platforms based on opendevelopment suites.

6.1. MOSES main results

MOSES can be viewed as a success case in thescope of EU projects [13] since, according to itsfinal review panel, it has achieved all the initiallyestablished objectives and has indeed addressedstandardization issues beyond the initial aims ofthe project. In fact, MOSES has established astrong relation with standardization activities, inparticular MPEG and its stakeholders (broad-casters, telecom operators, content and serviceproviders, research and academic and users atlarge), in order to help in achieving the develop-ment and implementation of the MPEG IPMP-Xstandard, the first DRM-related standard everreleased by ISO (in 2003) and the single one

published by ISO in the DRM arena, up to thewriting of this paper.6

MOSES has brought some differences, from thetechnological point of view, when compared withthe previous OCCAMM project, both in terms ofterminal-side technology and in the support ofserver-based DRM technology. Some of the newtopics developed by MOSES were:

�
The usage of IPMP Tools rather than IPMPSystems. While an IPMP System is a monolithicIPMP protection scheme which requires im-plementation-dependant access to protectedstreams at required Control Points and mustprovide any intra-communication within anIPMP System on an implementation basis, theIPMP Tools are modules that perform (one ormore) IPMP functions such as authentication,decryption, watermarking, etc. Conceptually,the use of one or more IPMP Tools is combinedto perform the functionality of an IPMPSystem. IPMP Tools, as opposed to IPMPSystems, are normatively identified as to whichcontrol points they function at as well as areprovided normative methods for secure com-munications both within as well as outside of agiven IPMP Tools comprised functional ‘‘IPMPSystem’’. An additional difference betweenIPMP Tools and IPMP Systems is that IPMPTools, or a combination thereof, may be usedfor the protection of Object streams;
�
Better-defined IPMP descriptors and associatedsystem syntax structures;
�
The existence of a Messaging Frameworkinstead of an API definition, between IPMPTools and the Terminal. This represented anevolution compared to the OPIMA specifica-tion which was API based, since messages canbe secured with just a digital signature whileinterfaces require much more effort;
�
An Abstract IPMP Control Graph that deter-mines the structure of protection;

ARTICLE IN PRESS


�
An Authentication Framework that enablesIPMP tools to perform mutual authenticationwith the terminal, in opposition to the OPIMAapproach which was based on a closed tamperresistance environment;
�
The development of an integrated server-basedDRM platform, composed of several distribu-ted components capable of fulfilling a specificrole in the media chain, based on openstandards and open-source technology.
The main MOSES results could be synthesizedon the following:

�
Close collaboration with ISO in the develop-ment and implementation of the MPEG-2/4IPMP-X standard, namely, help achieving‘‘consensus’’ and contribution in specifying,implementing (Reference Software) and validat-ing (Conformance Testing) the MPEG-2/4IPMP-X. It was the first ever implementationof IPMP-X;
�
Development of a set of content players andintegration of the MPEG-2/4 IPMP-X toseveral platforms (PC, PocketPC hand-helddevice and Symbian-based mobile devices). Thisrepresented the first implementation of mediaplayers, for several platforms IPMP-X capable;
�
Development of an open-source DRM archi-tecture to manage the content rights, referred toas OpenSDRM, Open Secure DRM;
�
Development of an e-commerce web-site fordigital music acquisition and consumption,referred to as Music-4You [43], which hasdemonstrated successfully the MOSES devel-oped DRM technology.
6.2. The MOSES MPEG IPMP-X implementation

Regarding the MOSES MPEG IPMP-X imple-mentation, the work consisted in the integration ofthe MPEG-4 IPMP-X in the IM-1 MPEG-4standard reference player and in the deploymentof a number of example IPMP Tools. The softwarewas developed for the PC and an optimizedversion was deployed for the PocketPC andSymbian mobile phone environments.

While binary normative messaging interfaceshave been used in MOSES for integration with anyMPEG-4 player (Fig. 6), the equivalent interfaceshave also been implemented in Syntactic Descrip-tion Language (SDL) for conformance reasonswith IM-1 MPEG-4 reference player rather thanupdating the latter [3,6]. Translation modulesamong SDL-based messages and binary ones havebeen also developed.

One major deviation from the former OPIMAIPMP philosophy was the usage of a MR insteadof OPIMA standardized APIs. This MR wascapable of routing messages from the IPMP toolto the player and TM and vice versa. The TM wasresponsible for the instantiation of the appropriateIPMP tools on the system which are needed torender the content. For more details on MPEG-4IPMP-X and its MOSES implementation theinterested reader should also refer to [52] and [6],respectively.

6.3. OpenSDRM, open secure digital rights

management

The MOSES MPEG IPMP-X module wasintegrated in a broader technological platform,addressing all the issues of DRM. This led to thedevelopment of an open-source DRM architectureto manage the content rights, referred to asOpenSDRM, Open Secure DRM.

The OpenSDRM architecture was developedtaken in mind that it could be adapted for use withseveral business models and different types ofcontent, aiming at enabling business involvingmultimedia content to function, by enforcinglicensing agreements for content use and offeringbusiness opportunities to the content rights ownerand content provider. At the time of development,various players and approaches in the DRM arenawere already in place. One of such approachesaddressed the DRM interoperability problembetween different actors of the value chain bydefining one unique media format and one type oftechnical solution used by every device. Theformat may be proprietary or open. The OpenMobile Alliance (OMA) [46] has targeted theDRM support for mobile phones and appliances,using an open specification. For the broadcast area

ARTICLE IN PRESS


and the home network Digital Video BroadcastDVB-CP/CPT [12] is an on-going step towards thestandardization of a Content Protection and CopyManagement System, within the home network.Other vendors [37,38,51] are developing their ownvertical strategies, i.e. they are seeking andcompeting to establish a ‘‘de facto’’ standard inthe DRM arena. Contrary to these efforts, theOpenSDRM DRM implementation has followed ahorizontal approach (in opposition to the verticalone described before). In this approach, theimplementation has followed the guidelines andspecifications of open standards, which address theDRM interoperability by defining common inter-faces, tools and mechanisms that different DRMsolutions should comply. To this aim OpenSDRMhas provided support to the following standards:

�
Open Digital Rights Language (ODRL/OMAprofile), a language for rights expression [47]derived from an international effort aimed atdeveloping and promoting an open standard forthe DRM expression language which has beenadopted by OMA;
�
MPEG-21 Rights Expression Language (REL),developed by MPEG-21 [33];
�
MPEG-2/4 IPMP Extensions (Section 4.2).
OpenSDRM is also based on the emergingService oriented Architecture (SoA) of the W3Cconsortium (this SoA is composed by three majorcomponents: Simple Object Access Protocol [55],Web Services Description Language (WSDL) [57]and Universal Description, Discovery, and Inte-gration [56]).

This DRM solution is composed of severaloptional elements, as depicted in Fig. 7, coveringthe content distribution value chain, from contentproduction to content usage. It addresses severalmajor aspects of the content distribution andtrading: content production, preparation andregistration, interactive content distribution, con-tent negotiation and acquisition, strong actors anduser’s authentication and conditional visualiza-tion/playback of content. OpenSDRM defines adistributed architecture in which every componentcan be separated. This allows the possibility to thearchitecture to be flexible to the addition of new

components or the substitution of same compo-nents with new ones supporting different function-alities, or the integration of the DRM platformwith third-party networked systems and services.These components can all work side by side aslong as the defined integration point is respected(defined by WSDL). The communication betweenthe single components will usually take placewithin insecure networks. Furthermore, the com-ponents communicate with a text-based protocol(eXtensible Markup Language, XML). This in-troduces special needs regarding the security ofthis type of communication.

Even though the MOSES project has addressedMPEG-4 content, the OpenSDRM infrastructurewas designed with the concern to be adaptable andapplicable to all types of content, business modelsand distribution channels (download, super-dis-tribution, streaming or even broadcasting). Thenext sections detail the External Components &Interfaces and the Internal Components & Inter-faces of OpenSDRM.

6.3.1. External Components & Interfaces of

OpenSDRM

This sub-section will present in detail thecomponents and actors that may interact exter-nally with the OpenSDRM architecture, namely,the User, the IPMP Tools Provider, the ContentProvider, the Payment Infrastructure and theCertification Authority.

�
The User represents a person who wishes toconsume a piece of content. This content mayor may not be protected. However, the way toaccess and display such content may require theuse of protected devices, software and licenses.The user will make requests to Open SDRM inorder to: identify him, download licenses andplay multimedia using a Media Player, em-bedded or not on a web browser. In a finalanalysis, the User interaction with OpenSDRMwill always result in one of two things: either theuser can play/render the content and enjoy it orhe/she cannot; being then informed of thereason for this prevention.
�
The IPMP Tools Provider is any organizationthat produces tools and technologies for

ARTICLE IN PRESS

Fig. 7. OpenSDRM general architecture.


encryption, scrambling, watermarking and othersthat can be applied to content protection. Thesetools will be made available to OpenSDRM foruse in content rights protection. These tools willneed to comply with some guidelines. Theseguidelines and a subscription, are translated intoa business relation that must exist between agiven Content Provider and the IPMP ToolsProvider, since mostly, a given producer and/ordistributor of content, may want to choose whichtype of protection the content will have and,respectively, which tools can be applied to thecontent and from which supplier.

�
The Content Provider is any multimedia con-tent supplier that feeds OpenSDRM with
content and optional metadata. The contentcan be complex multimedia content that isready for distribution, or simple content, e.g.JPEG images, that can be edited and combinedwith other content. As mentioned, the MOSESproject has addressed MPEG-4 content.

�
The Payment Infrastructure facilitatesOpenSDRM e-commerce features by providingservices for handling electronic payments. Theinterface between OpenSDRM and the Pay-ment Infrastructure is generic and independentof the payment method, allowing therefore amultiplicity of payment systems.
�
The Certification Authority is responsible forreceiving requests for and issuing credentials to

ARTICLE IN PRESS


entities. These credentials will be used byentities to authenticate themselves to eachother, allowing the establishment of secureand authenticated communication channelsbetween them. All the components in theOpenSDRM architecture communicate usingthe channel security provided by the SSL/TLSprotocol. This Certification Authority may beinternal to OpenSDRM, and therefore entirelymanaged by some entity, or it may be anexternal commercial Entity.

6.3.2. Internal Components & Interfaces of

OpenSDRM

In this part, the internal components of theOpenSDRM platform and the correspondinginterfaces are presented. These components in-clude: Media Application (MPL), Media DeliveryServer (MDS), Commerce Server (COS), Authen-tication Server (AUS), LIS, IPMP Tools Server(ITS), Registration Server, CPS, PGW and theConfiguration Server (CS).

�
Content Preparation Server (CPS): this servercomponent is responsible for the content pre-paration. It receives raw content from aspecified source or sources and encodes it on aspecified format, adds metadata and protects it.Under the MOSES project, content has beenencoded in MPEG-4 format, according to somepre-established templates. These templates willallow the creation of MPEG-4 files containingmusic files in MP3 or AAC format togetherwith some JPEG images about the album andartist.
�
Configuration Server (CFS): this component isresponsible for the storage and management ofthe locations of all the other components in thesystem. Any component that joins the systempublishes its own location on the CFS so thatother components can interact with it wheneverthey need to.
�
Payment Gateway (PGW): is a server compo-nent responsible for verifying and validating thepayment methods provided by the User for aCOS.
�
Commerce Server (COS): is a server componentresponsible for trading the content with the
users. Normally, content is chosen via webbrowser, some very generic metadata might beconsulted, information about the price is alsoavailable, and especially the content usageconditions might be established.

�
Media Delivery Server (MDS): is a servercomponent responsible for exchanging piecesof content with the client. This MDS willimplement a specific protocol (download:FTP, HTTP or other; streaming: RTSP orother; broadcast) to exchange protected contentwith the client MPL.
�
Registration Server (RGS): is a server compo-nent whose role is to assign unique identifiers tocontent and to register metadata informationfor that specific content. This architecture wasdesigned to be as close as possible to ISOstandards and therefore, for this unique ID,OpenSDRM follows the MPEG-21 directivesabout Digital Item Identification (DII) [32],using a reduced version of the MPEG-21 DIIDigital Object Identifiers [32].
�
Authentication Server (AUS): is responsible forauthenticating all the internal and external entitiesto the DRM system. It validates the access rightsof all the entities and components in the systemworking as a SSO point, registering and mana-ging components and users on the system. It usescryptographic XML credentials to authenticateboth components and users in order to authenti-cate the transactions exchanged between them(XML Encryption and XML Signatures).
�
License Server (LIS): is a server componentresponsible for house-keeping the rules asso-ciating a user, the content and his/her corre-sponding access rights. This component willaccept connections from authenticated MediaPlayers clients for downloading of licenses,which will be applied to the protected contentthrough an appropriate IPMP tool. The licensesare XML formatted using ODRL/OMA profile[47] or the REL, developed by MPEG-21 [33].Although these two languages are used for thesame functionality—rights’ expression—theystill do not interoperate. However, there isongoing work to create bridges between ODRLand MPEG-21 REL [50] and achieve interoper-ability between them.

ARTICLE IN PRESS


�
IPMP Tools Server (ITS): is the server compo-nent responsible for registering new IPMP toolsand for receiving authenticated client MPLrequests for the downloading of a specificIPMP tool. It is also responsible for makingIPMP tools available to the CPS to allow theprotection of content.
�
Media Application (MPL): this componentrepresents the software that will be used torender the content. This is a generic componentwith the particularity of being able to display/playback the appropriate content for which thenecessary audio/video codec should be available(if this codec is not available it must bedownloaded from a remote secure server). ThisMPL may work with one or several IPMP toolsin order to control how the content is accessedby a particular user. This component works onthe client side of the general architecture;however, it plays an important role in theDRM functions. The MPL design is fullycompatible with the IPMP-X design and tookinto consideration that content can be ex-changed on-line and off-line as well, since itsupports the ‘‘Tools in Content’’ functionalitywhere Content, Tools and Licenses can bepackaged and distributed, i.e. via Bluetoothtogether to a certain device.
6.4. MOSES user trial—Music-4You.com

The Music-4You web-site (www.music-4you.com), a digital music B2C e-commerce site, wasdeveloped to prove the technological conceptsbehind MOSES, i.e., the MPEG-4 player IPMP-Ximplementation and the OpenSDRM platformintegration. The content format adopted for thismusic web-site was AAC (Low Complexity Pro-file) wrapped in MPEG-4 File Format. Thus aspecific IPMP-X enabled MPEG-4 music playerwas developed and distributed to selected users,during the project lifetime.

Music-4You was developed with the purpose tobe a music portal, directed for two types of finalusers: consumers that wanted to listen to musicand to music bands (music providers). The portalaggregates the work of several bands, allowing

them to disseminate their work on the Internetwith little effort and investment, with the possibi-lity to protect their content according to theirwishes by filling on-line forms. On the other hand,consumers could access to a large set of free musicand to non-free music previews and downloads.

Another important Music-4You characteristic isthat its business model was built on the conceptthat protected content had no intrinsic value. Thisseems contradictory with MOSES objectives.However, what it really means is that users maydownload the content they want from the web-site,share it with their friends on P2P networks andpublish the content on web-sites and so on,because content is protected (ciphered). Thereforecontent by itself has no ‘‘real’’ value. What confersvalue to the content are the associated licenses(which contain associated rules of content usageand the corresponding decryption keys) persona-lized for a given user. This license is to be used bythe MPEG-4 player and the appropriate IPMPtool, which enforces the rules on the content anduses the appropriate deciphering key to render it.The licenses used by Music-4You are count-basedand time expiry-based. However, many otherusage conditions could be added to the licenses,which can be expressed in ODRL or in MPEG-21REL [10].

MOSES targeted not only the PC as the finaldevice, but also embedded devices, such as hand-held PDAs and Mobile Phones. The same archi-tecture, with the proper adaptations, tackled allthese devices to provide the same functionality–thepossibility to listen to music and at the same timeuphold the rights of the copyright owners. Aspecific Music-4You portal (Fig. 8) was developedalso for small screen rendering devices, such asPocketPCs.

Music-4You has brought clear innovations, as amusic portal, if we compare it with similar ones inoperation on the WWW in the end of 2003 [37].The main innovations are listed below:

�
Deployment of the first MPEG-4 IPMP-Xbased application: it was the first time that anMPEG-4 IPMP-X based application was de-ployed and tested on a trial, open to theInternet community in general, where users
http://www.music-4you.com


ARTICLE IN PRESS

Fig. 8. Music-4You main web-page.

7

and

dur

por


could experience controlled access to music;7

�
Contrarily to other solutions, and due to obviouscommercial limitations, Music-4You targeted amusic market niche composed mainly of amateurmusic bands that could upload their own musictracks and made them available on the Music-4You portal. The musicians were also responsiblefor defining all the information they would like to
Eighty users have participated in the controlled Project trails

more than 500 (general public) have accessed the site

ing the short period (end of 2003), when the Music-4You

tal was up and running.

publish on the portal, associated to their content,for which they owned the exclusive rights;

�
The Music-4You portal allowed the possibilityfor users to define the music access contractualconditions, varying the final price according tothe versioning choices made. This was identifiedas a more flexible business model than the onethat has been presented by most music storesavailable on the web, in which a price table isfixed [37,51];
�
The music obtained via download from Music-4You was completely ciphered. Any attempt tolisten to it without the appropriate license

ARTICLE IN PRESS


resulted in frustration. Therefore, the Music-4You portal could be seen not as a mereplace for buying music, but rather a place whereusers could buy licenses that would grant therights to access a certain version of the music.This set-up enabled users to share their ownmusic tracks with others (even on P2P net-works) without copyright infringement. Anyuser willing to listen to the music track wouldnecessarily had to acquire a license from theportal;

�
Finally, the portal supported the possibility toenjoy the same content on multiple devices,such as PCs and Pocket PCs.
7. Conclusions

The present document provided an overview ofthe evolution of the standardization work relatedto copyright protection of digital content andDRM, starting from OPIMA, through ISOMPEG IPMP ‘‘Hooks’’, towards the developmentof the ISO MPEG IPMP-X standard. TwoEuropean IST FP5 R&D projects—OCCAMMand MOSES were introduced, which have beenworking inline with the standardization bodies,such as MPEG. The paper explained how strongand important is the symbiotic relation betweenstandardization efforts and public European fund-ing of clearly focused R&D programmes. Wehave shown that IST OCCAMM and MOSEShave provided a significant contribution, both interms of knowledge and technological products,which will eventually help to strengthen theEuropean presence in the digital content market.The authors believe that market actors shouldharness the ability inherent in DRM of not justpreventing unauthorized uses but also of enablingnew business models in service and contentprovision. The content and distribution sectorshave begun to experiment with new distribution,pricing and revenue models and will eventuallysettle on the ones best suited for mass-marketconsumption of protected content over connecteddevices and networks. Interoperability of mediasolutions (formats and DRM), from multiplevendors, needs to be achieved so that users can

rely on the assumption of being able to consumethe services and content they may choose, fromthe CE equipment available to them. All theindustry sectors agree that industry-led standards-based solutions offer what is seen as the besteventual outcome, but standards take time todevelop and implement. It is important that DRMensures and enhances consumer choice and com-petition. Therefore, the European Commissionshould continue to foster deployment of openstandards [14] by continuing to support the workof MPEG, OMA, DVB and perhaps mostimportantly, the work by DMP [5,11,35,53] beingthe last hope of digital media consumers [8] world-wide to break the currently offered ‘‘walledgardens’’, while blossoming horizontal and inter-operable markets of digital media and otherrelevant standards bodies and appropriate forathrough European Collaborative R&D pro-grammes. Possible options for further considera-tion may include:

�
RELs translation, i.e. OMA REL vs. MPEG-21REL and/or the ability to download the clientof the required REL interpreter;
�
Conformance with open, transparent, and clearcriteria of end-user devices to specified trustlevels, perhaps by defining and applying aprofile of Common Criteria [9,44];
�
Rules for governance of trust authorities andagencies and their role in society.
References

[1] O. Bomsel, A. Geffroy, Economic analysis of DRMs,

deliverable DB.5.14_Economic analysis of DRMs_V1_0,

PF6 IST MEDIANET, December 2004.

[2] F. Chiariglione (CRL), P. Kudumakis (CRL), C. Alberti

(EPFL), A. Romeo (EPFL), M. Balestri (TILAB),

J. Trindade (ADETTI), J. Ming (PANASONIC), MOSES

implementation of MPEG-4 IPMP Messages—version 1.1,

Ref. as ISO/IEC JTC1/SC29/WG11/M10042, Brisbane,

Australia, October 2003. This contribution (software

library and documentation) consists in the core confor-

mance library and, as such, has been integrated in the

following standards: MPEG-2 IPMP Reference Software

(N6064) and MPEG-2 IPMP Conformance (N6062)

MPEG-4 IPMPX Reference Software(N5818) and

MPEG-4 IPMPX Conformance (N6065).

ARTICLE IN PRESS


[3] F. Chiariglione, P. Kudumakis, M. Balestri, MPEG-4

IPMP-X MOSES Interfaces, Ref. as ISO/IEC JTC1/SC29/

WG11/M9780, Trondheim, Norway, July 2003.

[4] F. Chiariglione, P. Kudumakis on behalf of MOSES EC

IST project, Distribution of digital content, Digital Media

Project, Contribution No. 56, Los Angeles, USA, April

2004.

[5] F. Chiariglione, P. Kudumakis on behalf of MOSES EC

IST project, Distribution of digital content, Digital Media

Project GA2, Contribution No. 56, Los Angeles, USA,

April 2004.

[6] F. Chiariglione, P. Kudumakis, MPEG-4 IPMP Exten-

sions for application developers, in: A User’s Guide to

MPEG Standards, to be published by British Standard

Institute, London, UK, 2005.

[7] L. Chiariglione, Interoperable DRM Platform (IDP),

Interoperable End-user Devices (IED) and short-term

IED (IED-s), DMP, 4 April 2004, http://www.chiariglio-

ne.org/contrib/040404chiariglione01.htm.

[8] L. Chiariglione, Collection of TRU Templates, Digital

Media Project, UK, 2004 DMP0270rev1.

[9] Common Criteria Portal web-site, http://www.

commoncriteriaportal.org/.

[10] ContentGuard and Central Research Laboratories colla-

borate to provide support for MPEG-REL within

MOSES, Bethesda, MD, USA, September 16, 2003,

http://www.contentguard.com/press_091603.asp.

[11] Digital Media Project web-site, http://www.dmpf.org.

[12] DVB TM CPT Copy Protection technical, http://

www.dvb.org/index.php?id=62.

[13] EU Funding Opens Up ‘On Line’ Music For The Masses,

London, FP6UK, October 28, 2004, http://fp6uk.ost.

gov.uk/page.aspx?sp=2228.

[14] High Level Group on Digital Rights Management, Final

Report, March–July 2000, http://www.fep-fee.be/drm.htm.

[15] IBC’03 Press Release, Industry join forces to support

MPEG’s Intellectual Property Management and Protec-

tion Extensions Framework, International Broadcasting

Convention (IBC’03), Amsterdam, The Netherlands,

September 12–16, 2003, http://avalon.cselt.it/projects/

moses/Public/docs/IPMPX%20PressRelease.pdf.

[16] IFPI, The recording industry commercial piracy report

2004IFPI, http://www.ifpi.org, 2004.

[17] IFPI, IFPI:05 Digital Music Report, IFPI, http://www.

ifpi.org, 2005.

[18] Internet Streaming Media Alliance (ISMA), Encryption

and Authentication Specification v1.0, Mountain View,

CA, USA, 2004.

[19] ISO/IEC 13818-1:2003, Information technology—generic

coding of moving pictures and associated audio informa-

tion—Part 1: systems, Amendment 2: support of IPMP on

MPEG-2 systems.



tion—Part 11: Intellectual Property Management and

Protection (IPMP) on MPEG-2 systems.



tion—Part 4: conformance testing, Amendment 1: MPEG-

2 IPMP conformance testing.



tion—Part 5: software simulation, Amendment 2: MPEG-

2 IPMP reference software.

[23] ISO/IEC 14496-1:1999 (MPEG-4 Systems, first ed.).

[24] ISO/IEC 14496-1:2001 (MPEG-4 Systems second ed).

[25] ISO/IEC 14496-1:2003, Information technology—coding

of audio–visual objects—Part 1: systems, Amendment 3:

IPMP Extensions.

[26] ISO/IEC 14496-1:2004 (MPEG-4 Systems third ed).


of audio–visual objects—Part 13: IPMP Extensions.


of audio–visual objects—Part 2: visual, second ed, 2001.


of audio–visual objects—Part 3: audio, second ed, 2001.


of audio–visual objects—Part 4: conformance testing,

Amendment 4: IPMP Extensions conformance testing.


of audio–visual objects—Part 5: reference software,

Amendment 4: IPMP Extensions reference software.

[32] ISO/IEC 21000-3 Information technology—multimedia

framework (MPEG-21)—Part 3: Digital item identifica-

tion.

[33] ISO/IEC 21000-5 Information technology—Multimedia

framework (MPEG-21)—Part 5: Rights Expression

Language.

[34] M. Koike, T. Kogure, N. Sonehara on behalf of the

Japanese Digital Cinema Common Specification Develop-

ment Committee (DCCSDC), Digital Cinema Distribution

Using MPEG-2 IPMP—Implementation Report and Issues

of Feasibility, ISO/IEC/JTC1/SC29/WG11/M11614, Hong

Kong, CN, January 2005.

[35] P. Kudumakis (inAccess Networks), Answer to the DMP

CfP (DMP0328) for stationary audio and video devices: a

unified approach to interoperable DRM Systems by

merging UPnP and the MPEG-2/4/21 IPMP family of

standards for PAV & SAV DMP, Digital Media Project

GA6, Contribution No. 0392, San Diego, USA, April

2005.

[36] J. Lacy, N. Rump, T. Shamoon, P. Kudumakis, MPEG-4

Intellectual Property Management & Protection (IPMP)

overview & aplications, AES 17th International Confer-

ence on ‘High Quality Audio Coding, Villa Castelletti,

Signa, Italy, September 2–5, 1999, J. Audio Eng. Soc. 47

(5) (May 1999) 392.

[37] R. Lenzi, et al., Apple iTunes Music Store, Technical

Report, The Interactive-Music Network, June 2003.

[38] Microsoft, Architecture of Windows Media Rights Man-

ager, Microsoft Corporation, http://www.microsoft.com/

windows/windowsmedia/howto/articles/drmarchitecture.

aspx, May 2004.

http://www.chiariglione.org/contrib/040404chiariglione01.htm

http://www.chiariglione.org/contrib/040404chiariglione01.htm

http://www.commoncriteriaportal.org/

http://www.commoncriteriaportal.org/

http://www.contentguard.com/press_091603.asp

http://www.dmpf.org

http://www.dvb.org/index.php?id=62

http://www.dvb.org/index.php?id=62

http://fp6uk.ost.gov.uk/page.aspx?sp=2228

http://fp6uk.ost.gov.uk/page.aspx?sp=2228

http://www.fep-fee.be/drm.htm

http://avalon.cselt.it/projects/moses/Public/docs/IPMPX%20PressRelease.pdf

http://avalon.cselt.it/projects/moses/Public/docs/IPMPX%20PressRelease.pdf

http://www.ifpi.org

http://www.ifpi.org

http://www.ifpi.org

http://www.microsoft.com/windows/windowsmedia/howto/articles/drmarchitecture.aspx



ARTICLE IN PRESS


[39] J. Ming, F. Chiariglione, C. Alberti, P. Kudumakis,

I. Kaneko, C. Schultz, MPEG IPMP Extensions FAQ

WD 1.0, ISO/IEC JTC1/SC29/WG11 N5790, Trondheim,

Norway, July 2003.

[40] J. Ming, C. Schultz, P. Kudumakis, Text of ISO/IEC

14496-5:2003/FDAM 4 (MPEG-4 IPMPX Reference

Software), Ref. as ISO/IEC JTC1/SC29/WG11/N6244,

Waikaloa, USA, December 2003.

[41] MOSES web-site, http://www.ist-moses.org/.

[42] MPEG Requirements Group, Call for proposals for IPMP

solutions, ISO/IEC JTC1/SC29/WG11 N3543, Beijing,

China, July 2000.

[43] Music-4You web-site, http://www.music-4you.com.

[44] National Institute of Standards and Technology, Compu-

ter Security Resource Center, Common Criteria web-site,

http://csrc.nist.gov/cc/.

[45] OCCAMM web-site, http://sharon.cselt.it/projects/

occamm/.

[46] OMA, Open Mobile Alliance, http://www.

openmobilealliance.org/.

[47] Open Digital Rights Language (ODRL) Version 1.1, W3C

Note, September 2002, http://www.w3.org/TR/odrl/.

[48] OPIMA Specification version 1.1, 11th Meeting, Turin,

2000.

[49] F. Pereira, T. Ebrahimi (Eds.), The MPEG-4 Book,

Prentice Hall, Englewood Cliffs, NJ, 2002.

[50] J. Polo, J. Prados, J. Delgado, Interoperability between

ODRL and MPEG-21 REL, First International ODRL

Workshop, Vienna (Austria), April 2004.

[51] RealNetwork Rhapsody, http://www.real.com/rhapsody/.

[52] T. Senoh, T. Ueno, T. Kogure (Matsushita Electric

Industrial Co., Ltd.); S. Shen, M. Ji, J. Liu, Z. Huang

(Panasonic Singapore Laboratories Pte Ltd.); C. Schultz

(Multimedia Architectures), DRM Renewability and

Interoperability, IEEE Consumer Communications and

Networking Conference (CCNC’04), Las Vegas Nevada,

USA, 5–8 January 2004.

[53] C. Serrao (ADETTI), M. Dias (ADETTI), J. Trindade

(ADETTI), P. Fonseca (ADETTI), P. Kudumakis (CRL),

F. Chiariglione (CEDEO), Answer to the DMP CfP

(DMP0145) for Portable Audio and Video Devices

(OpenSDRM), Digital Media Project GA4, Contribution

No 0216, Barcelona, Spain, October 2004.

[54] C. Serrao, (ADETTI), P. Kudumakis (CRL), C. Alberti

(EPFL), Joint answer to the MPEG-21 IPMP CfP on

behalf of MOSES, ENTHRONE and MEDIANET EC

IST projects, Ref. as ISO/IEC JTC1/SC29/WG11/

M10854, Seattle, USA, July 2004.

[55] SOAP, Simple Object Access Protocol, http://

www.w3.org/TR/soap/.

[57] WSDL, Web Services Description Language, http://

www.w3.org/TR/wsdl.

[56] UDDI, Universal Description, Discovery, and Integration,

http://www.oasis-open.org/committees/uddi-spec/doc/

tcspecs.htm#uddiv.

http://www.ist-moses.org/


http://csrc.nist.gov/cc/

http://sharon.cselt.it/projects/occamm/

http://sharon.cselt.it/projects/occamm/

http://www.openmobilealliance.org/

http://www.openmobilealliance.org/

http://www.w3.org/TR/odrl/

http://www.real.com/rhapsody/

http://www.w3.org/TR/soap/

http://www.w3.org/TR/soap/

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv

From OPIMA to MPEG IPMP-X: A standard's history across R&D projects

Documents

Transcript of From OPIMA to MPEG IPMP-X: A standard's history across R&D projects