content and service protection for iptv

IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009 425

Content and Service Protection for IPTVSeong Oun Hwang

Abstract—Content or service delivered through IPTV is highquality and of high economic value accordingly. As digital tech-nologies progress, illegal copy and redistribution of IPTV contentbecome easier and simpler. Therefore it is required to protectIPTV content or service. In this paper, following the approachestaken by ITU-T IPTV Focus Group, we analyze the securitythreats and requirements. We also discuss related issues and solu-tions for IPTV. Specially, interoperability issues among differentcontent and service protection systems are addressed.

Index Terms—CAS, content protection, DRM, IPTV, serviceprotection.

I. INTRODUCTION

I NTERNET Protocol Television (IPTV) is the use of an IPbroadband network to deliver television (cable TV type)

services to the end user. Traditional telecommunications ser-vice providers as well as alternate service providers and Internetservice providers can utilize their IP networks (and broadbandconsumer access) to deliver broadcast TV, Video on Demand(VOD) and other Internet services to the consumer.

IPTV is also defined as multimedia services such as televi-sion/video/audio/text/graphics/data delivered over IP based net-works managed to provide the required level of QoS/QoE, se-curity, interactivity and reliability (ITU-T IPTV FG 2006. 11).This will be available at http://ieeexplore.ieee.org.

IPTV services are already being offered by several telcosand Internet service providers worldwide. From countries tocountries or from service providers to service providers, eventhe same IPTV services can be under different stages such astrial or planning. This reflects that there exist diverse situationsincluding policies, legal systems, consumer’s attitudes, tech-nological infrastructures, etc. around IPTV. For the most part,IPTV service providers today are basically offering cable TVlike services—including premium channel services such as en-tertainment, sports, game and so on. Most service providers areproviding regular definition TV services at this time, but someare offering high definition TV (HDTV) service. Many serviceproviders are also offering VOD services which allow users toselect their favorite content such as video and audio.

Manuscript received May 01, 2008; revised December 11, 2008. First pub-lished May 05, 2009; current version published May 22, 2009. This work wassupported by the Hongik University new faculty research support fund. Thispaper has supplementary downloadable material available at http://ieeexplore.ieee.org, provided by the author.

The author is with the Department of Computer and Information Communi-cation Engineering, Hongik University, Chungnam 339-800, Republic of Korea(e-mail: [email protected]; [email protected]).

Digital Object Identifier 10.1109/TBC.2009.2020446

As digital technologies develop and IP infrastructures spreadwidely, traditional services which have been independently be-fore the IPTV era will take more advanced forms than now. Forexample, one can enjoy time-shifting or place-shifting of livebroadcasting more conveniently in IPTV than in non-IPTV. In-tegrated version of traditional services is one of the promising,new services unique to IPTV. One typical example of integratedservices is the so-called triple play service defined as provi-sioning of Internet, TV, and telephone service over a singlebroadband connection.

Many experts expect that other future capabilities of IPTVcould include whole house networking solutions to connect theTVs, PCs, in-home (or external) content storage devices andothers. The ultimate vision is to facilitate total interoperabilityamong and between all information, communications, and en-tertainment devices in the home, over one network within thecustomer premises [1].

The distinctive features of IPTV come from integration of IPnetwork and broadcast network, integration of existing, inde-pendent services, two-way communications between providerand consumer rather than the existing one-way communicationsfrom provider to consumer, and personalization, etc. Personal-ization is enabled and deepened by the two-way communica-tion network. That is, consumers now gradually interact activelywith the provision of the service and get differentiated person-alized service. It is sharply contrasted with the traditional wayconsumers just accept the provided service passively. Contentprovisioning service based upon a subscriber’s preferences canbe thought of one emerging example of such personalized ser-vices.

Content or service delivered through IPTV is required to beprotected because the provision itself is very high quality andof high economic value accordingly. In addition, the IPTV en-vironment means that the provision is shared among consumer’scomputers or portable digital devices. As it is well known, any-thing whose form is digital, whatever it is, can be shared on theInternet. Initially music files had been distributed through P2Pnetworks. Recently, copyrighted audiovisual contents are grad-ually distributed and shared illegally. As digitization of analogTV progresses, it is expected that illegal copy and redistribu-tion of IPTV content would be easier and simpler. As in thedigital TV, consumers can also make a complete copy of broad-casted IPTV content without degrading audio or visual qualitiesat all. The copy of broadcasted content is simply made by usingPVRs (personal video recorders) attached to the broadcastingreceiving devices. The most critical problem is that the illegalcopies can be redistributed in a very short time through the In-ternet.

The remainder of this paper is organized as follows. In Sec-tion II, we analyse the security threats, requirements and pos-sible solutions in IPTV which are drawn from the results of

0018-9316/$25.00 © 2009 IEEE

426 IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

Fig. 1. Security attack points and threats. This figure was slightly modified from one in [2]. Note that various security threats are scattered around the server sideas well as the client side.

ITU-T IPTV Focus Group. Section III analyses security issuesand mechanisms in a more generic viewpoint. Section IV intro-duces interoperable architectures for service and content pro-tection and its related scenarios proposed by ITU-T IPTV FocusGroup. We also discuss further open problems in Section V. Sec-tion VI concludes the paper with a discussion of the contribu-tion of the paper. The aim of this paper is to give both a generaloverview and in-depth discussions on some important securityissues and related protection systems for IPTV. Recent researchresults or technical details may be omitted for some parts.

II. SECURITY THREATS, REQUIREMENTS,AND POSSIBLE SOLUTIONS

A. Security Threats

This section describes a set of identified security threats ad-dressed by ITU-T IPTV Focus Group [2]. Prospective securitythreats can be classified into the following types: content se-curity threats, service security threats, network security threats,terminal device security threats, and subscriber security threats[2]. Fig. 1 shows the relationships among each of these threats.

1) Content Security Threats: This threat is mostly upon con-tent asset which belong to content provider, and can be con-sumed by the end-user via IPTV terminal device. The contentassets include real-time TV content, VOD content, PVR con-tent and downloaded applications, for example. Those contentassets are in danger of being attacked by crackers, professionals,insiders, and end-users in the form of interception, unauthorizedviewing and unauthorized reproduction or redistribution.

2) Service Security Threats: The service assets to be pro-tected include media servers, AAA (authentication, authoriza-tion, accounting) servers, service and content protection servers,content delivery network servers, and operational informationsuch as service logs and billing information. The types of ser-vice asset threats are as follows:

— Infringement of copyrights of the programs which IPTVservice platform provided to the subscribers. For example,attackers can cause financial damage to the copyrightholders by downloading and distributing copyrightedcontents illegally.

— Masquerading/spoofing IPTV service provider. For ex-ample, attackers can inject noise or unnecessary datainto the transmitted content for the purpose of derogatingthe reputation of the target IPTV service provider bydegrading the level of QoS.

— Malicious threats aimed at the IPTV servers (AAA servers,media servers, etc.) may include the cracking aiming atsecurity leaks in application software or communicationprotocol, denial of service attack, etc.

3) Network Security Threats: The network assets to be pro-tected include network equipments (e.g. routers, switches, gate-ways, DNS server) and network resources (e.g. bandwidth, mul-ticast services, etc). The network threats are listed as follows:

— Malicious attacks aiming at the network equipments orresources: attacks such as denial of service (DoS) to thebearer network or nodes in content distribution network.For example, attackers execute attacks such as TCP SYNFlooding, ICMP Flooding, Ping of Death, UDP Floodingand result in denial of service by exhausting the resourcesof the target of the attack.

— Security threats to multicast components used in IPTVbearer network such as masquerading/spoofing multicastTV sources, or illegitimate multicast group members. Forexample, attackers can have unauthorized access to multi-cast routers and modify the routing table.

4) Terminal Device Security Threats: The terminal assets be-long to IPTV terminal device, by which the end user can use toconsume and store content and other service related informa-tion. The terminal threats are listed as follows:

— Illegally accessing clear content by tampering devicehardware or software. For example, clear contents can be

HWANG: CONTENT AND SERVICE PROTECTION FOR IPTV 427

copied by bus data interception or SCP software cracking.The term of SCP (service and content protection) meansall the security and protection mechanisms for content andservice in IPTV.

— Illegally accessing keys or other secret information in de-vices using software cracking or hardware tampering. At-tackers can tamper the device memory or analyse the dataflow to obtain the keys and other secrets. Content key ex-posure results in content leakage and device key leakageleads to device impersonation.

— Device malfunctioning by hardware methods, such as con-trol of the device clock system to disable the functions ofthe SCP/CAS (conditional access system), or by softwaremethods, such as installation of viruses to exhaust the de-vice resources.

— The unauthorized applications (such as software pro-grams) were downloaded, run and stored in terminaldevices. With the help of these applications, the users canhave unauthorized access to the channels which are notpaid by them.

— The failure of the terminal equipments (hardware and soft-ware) caused by malicious codes/viruses from the net-work.

— The unauthenticated terminal devices connecting to thehome network.

5) Subscriber Security Threats: The subscriber assets to beprotected include assets, which belong to subscriber and con-sist of information about the subscriber (or subscriber house-hold), and his/her transactions, etc. One example of the sub-scriber threats is the theft of the subscribers’ private informa-tion such as subscription, billing, and identity information (e.g.login ID, password, address, viewing history and preferences)by malicious programs, such as Trojan horses.

B. Security Requirements and Possible Solutions

This section describes a set of security requirements whichwere drawn from the analysis of the above security threats [2].The requirements are divided into five requirements: content se-curity, service security, network security, terminal security, andsubscriber security. As Fig. 2 shows, the IPTV services consistof four entities including content provider, service provider, net-work provider and customer.

1) Content Security Requirements and Possible Solutions:The IPTV architecture is required to support content protectionwhile in transit, or in storage, or in re-distribution, and combi-nations thereof.

Traditionally, digital rights management (DRM) technologieswere developed to prevent users from unauthorized copying ofdigital content, to control the use of digital content, and furtherto enable the development of digital distribution platforms onwhich innovative business models can be implemented [3].They were originally intended to protect downloaded content,for example, mp3 audio files, at the end user’s PC environ-ment. As broadband network establishes and more demandfor audiovisual content increases, a need for the protection ofstreaming content emerges. Although research on VOD unicaststreaming DRM has been done actively, DRM research in a

Fig. 2. Service entity and security [2]. This figure shows the relationships be-tween the five security requirements and service entities.

multicast streaming environment has been partly done by a fewcompanies, whose approaches are very limited. Therefore wehave a strong need to develop DRM functions considering thefeatures of a multicasting service environment: large numberof user groups, real-time service requirements, support of a livestream, frequent changing of channels, and size dynamics ofusers joining/leaving channels at a particular time.

Another issue with DRM is that the existing DRM systemsare not interoperable at all. Until now, a lot of standardizationefforts toward DRM interoperability have been developed, butdoes not seem to make a big progress. The following shows abrief skim of the main activities towards DRM interoperability.Research and standardization activities are still under way. Wenote that most schemes except for OMA do not seem to bewidely used in the industry.

• Full-format interoperability (e.g., DMP [4], OMA [5])This approach has been adopted by most DRM standard-ization organizations and vendors. It seems to be one of themost complete ways of providing interoperability at firstglance. In fact, this approach has been successful at thelevel of particular application areas or systems. It seemshard, at least in the real world, for multiple vendors or or-ganizations to agree on a specific DRM scheme. Unlike thisapproach, MPEG has a totally different approach.

• Building block-based interoperability (e.g., MPEG 21 [6])MPEG does not try to standardize the DRM itself. Rather itthinks DRM themselves (which they call ‘DRM tools’) arehard to standardize. Therefore it focuses on the interfacesbetween DRM modules and their surrounding terminals.Under the assumption that all the terminals and applica-tion players can access to all the DRM tools (authentica-tion, encryption/decryption, watermark, and so on) as nec-essary, the approach is to search/download and use the ap-propriate tools when consuming a protected content. Com-pared to other approaches, it is highly flexible. However, inreality, only a particular tool can be available to a particularplatform. In addition to the above two approaches, the fol-lowing TTP-mediated transformation approaches are usu-ally used in the real world.

• Transformation-driven interoperability (e.g., Coral [7])


Fig. 3. Simulcrypt. Note that on the head-end side, several conditional access systems with their own ECMs can be deployed using a common scrambling algo-rithm.

This approach assumes the existence of a TTP (TrustedThird Party) connected to the network. A TTP provides in-teroperability by giving transformation or mediation oper-ations between different formats including protected con-tent formats, rights, and messages. We should notice thecorrectness problem regarding transformation operations.Transformation operations are likely to incur informationloss which may occur during incorrect mapping from thesource to the target DRM scheme. For example, a usageright specified in the source DRM scheme might be trans-lated into an incorrect one at the target DRM scheme.

2) Service Security Requirements and Possible Solutions:The IPTV architecture is required to support a mechanism toallow for the confidentiality/authenticity/integrity of signalingmessages between the SCP server and the SCP client in theIPTV terminal device. To support multiple service protectionsolutions, the IPTV architecture is prohibited from precludingsupport for necessary mechanisms to deploy specific serviceprotection system among them and to verify the deployedsystem. The IPTV architecture is also recommended to supporta capability to the head-end to support multiple scramblingalgorithms.

Conditional access (CA) is a service that allows broadcastersto restrict certain programs to certain subscribers, by scram-bling the broadcaster’s programs. The sent programs shouldbe unscrambled at the receiving end for viewing. Conditionalaccess used in the DVB (Digital Video Broadcasting) systemconsists of four functions: scrambling, entitlement controlling,entitlement management, and descrambling. The scramblingfunction scrambles the service by encrypting the programs ofthe serviced channel using the secret control words (CW). Todescramble the service, an authorized receiver should receivean appropriate entitlement. The entitlement controlling func-tion broadcasts the service access conditions, together withencrypted secret codes (the CW(s)) to authorized receivers.The entitlement management function distributes entitlementsincluding service keys to receivers. The service key to be usedfor the decryption of CWs is sent to the smart card, where itis decrypted using the smart card key. Descrambling of thechannel is done using the decrypted CWs at the receivingend. The DVB specification specifies the algorithm to use toscramble a DVB stream: it is called the DVB Common Scram-

bling Algorithm (DVB-CSA). This algorithm is standardizedbut is not public.

DVB had discussed a lot about standardization of CAS. Toensure the security of the system, diverse ways of service pro-vision, and market competitions, it has been decided that theconditional access system need not be standardized, althougha common scrambling algorithm is provided. But it providedtwo ways to provide interoperability between different CASs:Simulcrypt and Multicrypt.

In the case of Simulcrypt [8] based on DVB-CSA, each ser-vice is transmitted with the entitlement messages for a numberof different proprietary systems, so that decoders using differentconditional access systems (in different geographic areas) candecode the service. Simulcrypt requires a common frameworkfor signaling the different entitlement message streams. Simul-crypt provides the ability for multiple CA systems to controlaccess at the same time to a single content stream. Fig. 3 showshow the Simulcrypt works. The Advanced Television SystemsCommittee (ATSC) has adopted the Simulcrypt approach withits own common scrambling algorithm, ATSC-CSA [10].

A second solution, Multicrypt [9], is based on a standard-ized interface between a module and a host where CA and moregenerally defined proprietary functions may be implementedin the module. This solution also allows broadcasters to usemodules containing solutions from different suppliers in thesame broadcast system, thus increasing their choice and anti-piracy options. Multicrypt uses common receiver/decoder ele-ments which could be built into television sets. To implementMulticrypt, the interface called Common Conditional AccessInterface are defined between a host and a conditional accessmodule. Conditional access modules from different system op-erators can be plugged into different slots in the common re-ceiver/decoder, using the common interface. Fig. 4 shows howthe Multicrypt works.

The choice of Simulcrypt or Multicrypt is optional. The DVBorganization has decided that either approach can be used by theoperators. Both of these architectures can be used for satellite,cable, and terrestrial transmission of digital television.

The fundamental weakness of DVB CA system is the relianceon an unchanging key in the conditional access module, whichis usually implemented as a smart card. It is reported that attackshave happen through the spread of counterfeit smart cards in the


Fig. 4. Multicrypt. The Common Conditional Access Interface allows the useof several different conditional access modules on the user side.

real world. In the IPTV environment with a return channel, it isrequired a mechanism to stop such attacks using cloned smartcards.

3) Network Security Requirements and Possible Solutions:The IPTV architecture is required to support the capability ofpreventing attacks such as DoS attack, worm attacks, attacks inmulticast capabilities and to support the provision of measuresto block illegal or unwanted traffic or unauthorized access to net-work topology and its resources. To protect network resourcesfrom the attacks, the providers can deploy various network pro-tection mechanisms such as intrusion detection systems, firewallsystem, network encryption system, etc. In the following, weexplain some protection measures which are taken in the broad-casting community.

In DVB IPDC [11] and OMA BCAST [12], content/serviceis encrypted using a symmetric encryption algorithm. The en-cryption can be performed at the link layer (IPsec), session layer(SRTP), or content layer (ISMACryp).

In DVB IPDC, the broadcast network may use IPsec [13] toprotect broadcast services. All devices shall support IPsec atthe operating system levels. If IPsec is used for encryption ofIPDC, the encryption algorithm for IPsec shall be AES-128-CBC, as defined in [14] and [15]. The authentication algorithmfor IPsec shall be HMAC-SHA-1-96, as defined in [16] and [17].To protect an RTP session in DVB IPDC, the broadcast networkmay also use SRTP [18]. The encryption algorithm for SRTPpackets shall be AES-128-CTR. The authentication algorithmfor SRTP shall be HMAC-SHA-1-80, as defined in [16].

ISMA Encryption & Authentication Specification V. 1.0(also called ‘ISMACryp’) [19] defines an end-to-end contentencryption system for media carried over RTP streams and ISObased media files. The purpose of ISMACryp is to provide in-teroperability between ISMA-compliant [20] streaming serversand players, when protection is added in an ISMA-compliantenvironment. ISMACryp describes how to encrypt, authenticateand packetize MPEG-4 contents. The default cipher and modeis AES-CTR cipher with 128-bit key [21]. Individual AccessUnits, i.e., elementary audio video samples are encrypted usingAES_128_BYTE_CTR mode. The default message authenti-cation algorithm is SRTP with an HMAC-SHA1 with an 80-bitoutput tag and a 128-bit key [18].

The current available technologies or their combinations arethought of appropriate in coping with the above mentioned net-work security, although they may not exhaustively address allthe network security issues.

4) Terminal Security Requirements and Possible Solutions:The IPTV architecture is basically required to protect and au-thenticate terminal devices. Worm virus related attacks can bedealt with the measures which are deployed in network secu-rity requirement section. In addition, the IPTV architecture isrequired to support physical protection of sensitive security pro-cesses (e.g., descrambling, content tracing) and components in-volved in case no logical protection (e.g., encryption, water-marking) is present. Another emerging threat to the terminal se-curity is, while the protected content is transmitted from the au-thenticated terminal device to other devices which are attachedto the terminal, attackers can intercept the transmitted signal onthe digital bus. To cope with this problem, copy protection tech-nologies such as DTCP [22], CPPM/CPRM [23], and HDCP[24] were proposed.

The IPTV architecture is required to support secure downloadand installation of the SCP operating code to IPTV terminal de-vices. DCAS was proposed by CableLabs [25]. DCAS (down-loadable CAS) is a combination of traditional conditional accesssystem and the software download model. A hardware modulecalled secure processor in the user’s set-top box interacts withdownloaded security software to permit access to the contentbeing received. DCAS enables transfer of content from a set-topbox to user’s other devices such as a personal media player or amobile phone, equipped with the secure processor.

5) Subscriber Security Requirements and Possible Solutions:The IPTV architecture is required to support user privacy pro-tection and to allow a subscriber to set an access control mech-anism (e.g., a password) in order to restrict access to contentand/or services. It is also required to allow for a mechanismfor a subscriber to request extensions (e.g., more plays, moreplay-time) to digital rights associated with specific content in-stances. The IPTV architecture is also recommended to allowthe end user (as rights allow) to change, i.e. replace, an IPTVterminal device without inherently affecting its rights to con-sume content.

The concept of domain in protection system originally wasproposed to allow content sharing among devices owned by anentity, for example, the same household [27]–[29]. DVB CPCM[26]—a technical and architectural framework for the DVB forthe persistent protection and management of content deliveredvia broadcast, the Internet, or mobile—supports the concept ofAuthorized Domain (AD) which allows users to use their con-tents even at secondary devices in the sense that they does notdirectly receive or acquire the contents. AD is a logical groupingof all the CPCM-enabled devices belonging to one household.Therefore, mobile devices or devices in the car or stationary de-vices at home/secondary residence can comprise an AD. TheAD is intended to achieve a trusted environment for the legit-imate use of content by member devices by enforcing appro-priate policies and rules. In result, free place-shifting and useof contents is allowed among devices belonging to an AD. OneCPCM-enabled device can join only one AD, and the AD-boundcontent can be consumed within the AD only. AD is optional in


DVB-CPCM. All CPCM devices are not to be AD aware. Oneof distinguished features of DVB-CPCM AD is, the AD can beformed and managed autonomously. There is no requirement tobe able to link a particular AD to its owner(s) or its location(s).In contrast, most domain-supporting protection mechanism in-cluding OMA, xCP [30], DMP requires connection to outsideservers such as key management server or domain managementserver. Most of the time, users have some difficulty in setting uptheir own devices. Therefore, the most important requirementto be considered in implementing the domain concept is to pro-vide appropriate trade-off between security, usability, and trans-parency (does the user need to realize she is involved in a do-main management protocol? does the user need to realize this?)to the user. To reduce the difficulty or complexity a user mightfeel during domain registration/join/leave etc., xCP supports au-tomatic domain management method that does not require theuser’s involvement.

III. GENERIC SECURITY ISSUES AND MECHANISMS

This section discusses generic security issues and mecha-nisms for the overall IPTV infrastructure.

A. Selective Encryption

As the IPTV service environment features a large scalenumber of concurrent users, the encryption mechanism shouldbe scalable accordingly. Therefore, it is needed to developencryption techniques that are efficient in the process of de-cryption of the multimedia data as well as ensuring appropriatelevels of security. Selective encryption is one approach toreduce the computational requirements for huge volumes ofmultimedia data, mostly on the IPTV receiving side. Real-timedecryption is critical to the performance of IPTV receivers,for example set-top boxes. To alleviate a delay time occurringduring the decryption process, a selective encryption scheme isrequired that allows us to select portions of a multimedia datastream for encryption. Several methods have been done, butmost of them have not been known significant in the amount ofreduction with respect to total encryption. To name a few,

— Encryption of I frames only reduces the computations by50% [31].

— Encryption of all I-block raises several problems: Identifi-cation of I-blocks in a P or B frame introduces the overheadof searching the MPEG stream; some MPEG streams con-tain I frames only, reducing the selective algorithm to fullencryption [32].

Selective encryption can also serve to reduce channel changetime (“zapping time”), which is one of the most critical pendingissues to be addressed in IPTV. Therefore, we need to researchfurther on the encryption techniques suitable for multimediadata which can reduce the total encryption/decryption time.

B. Scalable Group Key Management

The IPTV security solution is required to be scalable to sup-port the protection of content that is distributed simultaneouslyto a very high number of subscribers. Scalable key manage-ment means a key management scheme to handle a larger groupof members without considerable performance deterioration. Inmulticast streaming service environment unlike unicast, encryp-

tion of data with a shared key among the members of a group,not individuals is required. When a user joins a particular ser-vice, the related service entitlement is given to the user by trans-mitting the group-shared keys. Therefore when there is a changein membership, the group key should be changed so that theleaving member cannot access new broadcasts or a new membercannot access old broadcasts. Particularly when users changechannels, real-time switching of channels without any recogniz-able delay should be provided at the user’s viewpoint. Existingapproaches deployed by most VOD DRM systems and a fewmulticast DRM systems using a separate key transport channelper user are not appropriate in a multicast streaming service en-vironment because a sudden increase of users joining in a mul-ticast streaming service usually causes substantial overhead or asystem failure at the key server. To deal with this problem, thereis an approach called key packet insertion scheme [33] which isvery similar to CAS: In the scheme, key packets are insertedinto the multicast streaming channel rather than opening sepa-rate key transport channels per user.

C. Watermarking

Besides encryption technology, an information hiding tech-nique such as watermarking can be used for content protection.A watermark (also called media watermarking) is a signal addedto digital data (audio, video or images) that can be detected orextracted later. Watermark signal serves various purposes suchas ownership assertion and usage control in content and serviceprotection area. In order to establish ownership over some con-tent, the owner can embed his or her private key into the content.The owner then publishes the watermarked content. Later, theowner demonstrates the presence of the watermark in the wa-termarked content using the unmarked content which is ownedby the owner only. In this way the owner can assert his or herownership of the watermarked content [34]–[37]. Watermarkingcan be further used for software protection. Like media water-marking, the software watermarking embeds a structure intoa program such that the extractability of from allows theparty to argue the ownership of the watermarked software [38],[39]. Software watermarks can be classified as static [40]–[43]or dynamic [39], [44]. A static software watermark is one in-serted in execution file such as data, text, or symbol section ofcodes. In a dynamic software watermark, some predefined se-quence of input to a program causes the watermark to be ex-pressed, or extracted. A static watermark is susceptible to a se-mantics-preserving program transformation such as code opti-mization. A dynamic watermark is highly susceptible to a tech-nique such as code obfuscation which results in changing theexecution state of a program while preserving the semantics.There is no generic watermarking mechanism which is immuneto all types of attacks known so far. From a practical point ofview, we need to select or adopt one or combinations amongexisting watermarking techniques that are considered to be ro-bust in our threats model.

D. Fingerprinting

We observed that encryption technologies can be useful to ac-cess control. However, the encryption technologies have a lim-itation that it cannot provide any type of protection once the


Fig. 5. Mediator based SCP interoperable architecture [2]. A mediator existsand processes interoperable transmission between two different SCP systems.

content was distributed as decrypted. To cope with this situation,fingerprint schemes are proposed by the industries such as Digi-marc, Macrovision and Philips. To trace unauthorized duplica-tion and distribution of publicly available multimedia content, aunique watermark called fingerprint can be embedded into eachcopy of the data usually while the data is used or played. If unau-thorized copies are found later, the traitor (the term specifies auser who distribute copies of the data in an unauthorized way)of the copy can be determined by retrieving the fingerprint [45].However, fingerprinting techniques have some difficulty in im-plementing the concept itself because it needs writing user’s in-formation over the content in real-time way. Although it is dif-ficult to implement secure, robust fingerprinting in real-worldapplications, it is viewed as one solution to analog reconversionproblem, which reflects the following phenomenon: Copy-pro-tection mechanism of digital content can be circumvented byreproducing the content in analog format and then reconvertingthe result in digital format.

IV. INTEGRATION OF DIFFERENT PROTECTION SCHEMES

In order to support the seamless time-shifting service (thatis, subscribers can store the content and retrieve it later) andplace-shifting service (subscribers can consume the contentanywhere), it is necessary to support service and content pro-tection interoperability where the applied security mechanismsare different. The IPTV architecture is recommended to supportthe capability for authenticating and authorizing end usersfor content sharing services (e.g. content export and contentredistribution). In the following, we describe SCP interoperablearchitecture and service scenarios proposed by ITU IPTVFocus Group. The scope of interoperability of SCP focuses onIPTV terminal device and other device, and is not involved inSCP server in head-end.

A. SCP Interoperable Architectures

Two kinds of possible SCP interoperable architectures areconsiderable as shown in Figs. 5 and 6.

One is based on mediator-based interoperability architecture.This interoperability architecture uses a mediator system, which

Fig. 6. Standard protocol based SCP interoperable architecture [2]. Two dif-ferent SCP systems exchange information based upon pre-defined standard in-terfaces and protocols.

is located in the middle of two SCP systems, to process interop-erable transmission. Coral takes this approach.

In the following, we describe function blocks on the aboveinteroperable architecture in detail:

1) Authentication & Authorization: Each SCP party shouldjudge whether the other party is proper target to achieve SCPinteroperability. It is usually accompanied with mutual authen-tication process as a preliminary step between two SCP par-ties. Device authentication is used in the area of content/ser-vice protection. Device authentication is divided into two cat-egories: hardware authentication and software authentication.For hardware authentication, it is required to establish technicalspecifications to exchange device information such as manufac-turer’s information, product model, serial number and so on.To prevent unauthenticated or malicious software module to beimported, it is required to establish authentication proceduresto verify that the participating software is trusted one. X.509certificate are generally used for device authentication, whichare generally are issued by licensing authorities and embeddedinto the product by manufacturers. For example, the authenti-cation mechanism of OMA DRM is based on X.509 public keycertificate. MPEG-21, by contrast, specifies a specific authenti-cation mechanism based on conversational negotiation. UnderMPEG-21 scheme, any authentication mechanism such as anX.509 public key certificate, Kerberos shared-secret tickets, orpassword digests can be deployed.

2) Content Adaptation: Content adaptation is responsiblefor converting cryptographic algorithm as well as content itself.Given several pre-defined standard encryption algorithms willfacilitate these processes. During this adaptation, it is very im-portant to ensure that the key material and security-critical in-formation are not disclosed. SCP providers are very reluctantto make their encryption details or key management architec-ture public, which may result in any threats to their SCP sys-tems. They usually adopt ways of establishing secure channelswithout disclosing their respective technical details to their com-municating parties.

3) License Adaptation: License adaptation is responsible forconverting licenses. A set of rights mapping (rights expression


Fig. 7. SCP interoperability mode [2]. This figure shows three different ex-change modes of protection systems amongst SCP modules.

mapping and semantic mapping) may be included in the licenseadaptation.

Different SCPs use different rights expression languageswithin their license formats. A REL (Rights Expression Lan-guage) is concerned with structuring and expressing a userights. The real world wants interoperability in the rightsexpression model, for example between the ODRL [48] series(OMA REL) and XrML [49] series (MPEG-21 REL, MicrosoftREL). However, it is not straightforward to directly translateeach other. As it is well known, those RELs originated at thesame languages, the DPRL [50]. Therefore they are broadlyvery similar in structure and semantics. The paper [51] con-cludes that direct translation between ODRL and XrML ispossible without loss of information except for several complexcontexts and situations. This strengthens the possibility oftranslation among different RELs. In CAS, content or serviceproviders use CCI (Copy Control Information) to specifywhether the target content/service should be encrypted or not.CCI can represent information such as ‘Copy Free’, ‘CopyOnce’, ‘Copy No More’ and ‘Copy Never’. DVB CPCM usesUsage State Information (USI) [52] to express the authorizedusage of a content item.

4) Metadata Adaptation: Metadata adaptation is responsiblefor converting metadata information. The temporal or standardmetadata, which is known by both parties, should maintain thesame information as the original metadata had. A set of metadatamapping (syntax and semantic mapping) may be included in themetadata adaptation. Also, metadata adaptation may be respon-sible for repackaging metadata information and securely deliv-ering it to the other SCP party. Various metadata schemes appro-priate for the characteristics of content are proposed [53]–[60].

B. Exchange Modes of Protection Schemes and Scenarios

Interoperability issues happen at home environment wheredifferent protection schemes are integrated. In the following, wedescribe three exchange modes of protection schemes and sce-narios where convergence between SCPs occurs. The followingFig. 7 illustrates a model of the case described above.

1) SCP End-to-End (SCP-EE): Using a single SCP, two ormore devices exchange and access content according to grantedrights. Even in case of redistribution, content is redistributed thesame without any change of format. This mode is the simplest

Fig. 8. Basic content management model [26]. A DVB CPCM content can betransmitted to other DVB CPCMs or compliant devices under the granted rights.

mode to implement but has constraints that all the terminal de-vices share the same protection technology.

We can see the example of this mode in DVB CPCM as shownin Fig. 8.

A DVB CPCM Instance, i.e., any device that implementsCPCM functionality in a compliant manner, implements theCPCM Security Control functionality. This enables the CPCMDevice to interoperate with other CPCM Devices to performcompliant exchange of CPCM Content and other CPCM func-tionality. CPCM Content that is exchanged directly betweenCPCM Instances in different CPCM Devices is inherently pro-tected by the CPCM System as considered the set of all com-pliant CPCM Devices.

2) SCP Bridging (SCP-B): On a single device, two or moreSCPs are deployed. Content acquired via one SCP system(from a network for example) can be accessed via another SCPresident on the same device according to granted rights. In thismode, SCP server supports two protection services, one forSCP-1 and another for SCP-2. This mode has an advantagethat SCP server controls all the service terminals, but results inadditional overhead over IPTV systems and network.

Interoperability approach based on Coral’s framework can beclassified into three categories depending on network boundary:online model, hybrid model and offline model [7]. The net-work boundary defines the separation between services that areavailable via the Internet and services that are deployed locallywithin a home network or LAN. Both online model and hybridmodel belongs to the SCP bridging case. In the online model,both the rights and the content are transferred using online ser-vices. In the hybrid model, as with the online model, the rightsare transferred using online services. The content, however, isnot acquired online but transformed locally, where repackagingof the content occurs on the device.

3) SCP Interchange (SCP_IX): This mode is characterizedby two or more devices, each device having one or more de-ployed SCPs. Content acquired by one device through one ofits SCPs can be securely transferred to and accessed on anotherdevice through a different SCP according to granted rights. Thismode can be applied only to the first receiving devices, whichconvert and transmit it to another device. In this mode, SCPserver does not directly control all the terminal devices withinthe home. To support this mode, additional performance is re-quired on the broadcasting receivers.

Coral’s offline model corresponds to the SCP Interchangecase. In the offline model, the complete interoperability func-tionality is on the user’s device: both the rights and the content


are transferred locally. This approach has a distinguishable ad-vantage when the content volume is large or it takes too muchtime to transform the content format, which is most common inthe multimedia environment. The challenge, however, is to es-tablish a trusted environment, which ensure that users consumeprotected content under the authorized rights and conditions.

In the following we describe three possible scenarios whichneed SCP interchange between service security and content se-curity.

Definition of terms used in the diagram:• SCP_IN: An input port from which IPTV content protected

by SCP comes in.• SCP_OUT: An output port to which IPTV content pro-

tected by SCP goes out.Scenario 1: SCP with SCP_IX (Fig. 9): The content

protected by SCP1 arrives at the terminal, and then may beexportable to a device having SCP2 . SCP_IX in IPTV TD(terminal device) supports interoperability between SCP1 andSCP2. The transformation may be done real-time as soon as thecontent arrives. This is the most common case where we cansee in the current consumer environment. For example, whilewatching the content on the original receiving device, the usercan stream it to another device when having the proper rights.

Scenario 2: SCP with optional SCP-B and storage (Fig.10): The content protected by SCP1 arrives at the terminal, andthen may be exportable to a storage device with SCP2. Protectedcontent must be protected on the storage device as well. Thetransformation may be subject to the governing rules providedby the service provider. In this case, while watching the contenton the original receiving device, the user can record it whenhaving the proper rights.

Scenario 3: SCP with storage and SCP_IX (Fig. 11): Thecontent protected by SCP1 arrives at the terminal, and may bestored as arrived in the internal storage, but be exportable to adevice having SCP2. Protected content must be protected on thestorage device as well.

SCP_IX in IPTV TD supports interoperability betweeninternal content protection mechanism and external one. Thetransformation may be done on demand after the content ar-rived. For example, while watching the content on the originalreceiving device, the user can record it; and later send it toanother device when having the proper rights.

C. Further Integration Issues of Protection Schemes

The following discusses further interoperability issues thatare to be considered when integrating protection schemes.

1) Key Management: Content and service access controlbased upon encryption is done via key. Key managementinvolves the processes of creation, distribution, update, andrevocation of keys. Key management is the most critical part ofa security system. Most vendors keep internal structure of keymanagement top secret. Therefore key management is the mostdifficult part to standardize. Most standardization specificationskeep this part out of their scope of standardization.

The following specifies key management mechanisms thatare being used for IP based broadcast/multicast system suchas DVB-H or OMA BCAST. DVB-H specifies two alternativeprofiles, the Open Security Framework (OSF) and 18Crypt in

Fig. 9. SCP with SCP_IX [2]. Note that the content receiving device transformsthe content according to the SCP of the target device.

Fig. 10. SCP with optional SCP-B and storage [2]. Note that the content canbe recorded according to SCP2.

Fig. 11. SCP with storage and SCP_IX [2]. Note that the content receivingdevice supports interoperability between internal content protection mechanismand external one.

[11]. OMA BCAST [12] defines two profiles, the SmartcardProfile and the DRM Profile. The DRM Profile is based onpublic key based mechanisms. It uses the RO (Rights Object)as specified in [5] to support key management on the interactivechannel. In case of broadcast channel, Broadcast Rights Object(BCRO)—broadcast extensions for OMA DRM v2.0 as speci-fied in [61] are used. The Smartcard Profile is based on existingsecurity technologies and standards defined for 3GPP [62] or3GPP2 [63].

The key management mechanisms deployed by both DVB-Hand OMA BCAST are based upon the so-called 4-layer keymanagement architecture:

(1) Content/service Protection layer: The content/service isencrypted by a symmetric encryption algorithm usinga Traffic Encryption Key (TEK). The encryption canbe performed at the link layer (IPsec), session layer(SRTP), or content layer (ISMACryp by encryptingAccess Units before packetization occurs) as describedabove.

(2) Key Stream layer: TEKs are delivered to devices usingthe KSMs, also known as Short Term Key Messages(STKMs) in both 18Crypt and OMA BCAST and as En-titlement Control Messages (ECMs) in OSF. It allowsthe terminal to reconstruct the TEKs needed to decryptthe content/service. KSMs may contain additional infor-mation to control access to the content service, such asaccess criteria. OSF defines the ECM stream signalingbut defines the format and content of the ECM as privateto the KMS. 18Crypt and OMA BCAST specify the keystream layer in detail.


(3) Rights Management layer: Content/service accessrights are delivered to devices using the Key Manage-ment Messages (KMMs), also known as Long TermKey Messages (LTKMs) in both 18Crypt and OMABCAST and as Entitlement Management Messages(EMMs) in OSF. The content/service access rights canconsist of a Service Encryption Key (SEK), used to ac-cess the KSMs and/or information such as entitlements.OSF defines the EMM stream signaling but definesthe format and content of the EMM as private to theKMS. 18Crypt and OMA BCAST specify the rightsmanagement layer in detail.

(4) Registration layer: Key material and metadata are ex-changed during the registration phase that will enabledevices to decrypt and authenticate rights and subse-quently access content/services. OSF leaves both theKSM and KMM streams as private, allowing the possi-bility to deploy a Key Management System that definesboth the Key Stream and Rights Management layers. Inthis way, OSF supports Simulcrypt allowing any KMSor multiple KMSs to control a single protected mediastream. In contrast, 18Crypt defines in detail layers forKMMs and KSMs by referring OMA. To ensure max-imum interoperability, OMA BCAST defines a commonlayer for traffic encryption (content/service protectionlayer) and allows the other layers of key managementto be implemented using either the DRM Profile or theSmartcard Profile.

As we can see in the case of ISMACryp, the interoperabilityis dependent upon and limited by KMS. The open approachbased upon 4-layer key management architecture taken byOSF is considered to the most practical way to achieveinteroperability among different content and service protectionsystems.

ISO Base Media File Format is also widely used to provide ageneral structure (e.g., Item Protection Box, Protection SchemeInformation Box) to signal and to document all the informa-tion such as the original format of the media, the encryptiontransform applied and its parameters, the kind and location ofKMS, and so on [64]. This method allows any proprietary pro-tection scheme to be used by registering the protection schemeat http://www.mp4ra.org.

2) Secure Download of SCP Client: It is not practical topre-load at manufacture time every IPTV terminal device withevery SCP system that market forces will demand. Thus, a se-cure mechanism for downloading and executing a selected SCPsystem onto a terminal device is needed. Elements such as se-cure boot-loaders and secure download protocols play a part inthis area of interoperability. For secure and authenticated down-load and installation of SCPs, digital signatures can be used.Digital signature can be generated only by an owner of signa-ture keys and verified by public.

It is important to note that in practice each SCP is constructedindependently of one another. It is possible that an integratedsystem of SCPs might be insecure together even if they are eachsecure in isolation. It means that incorporation of any part orinformation of a SCP system into another SCP system may raisesecurity breach in the aspects of integrated system, if any.

3) Interoperability Among Heterogeneous Domains: Theconcept of domain is widely and gradually deployed by serviceand content protection system provider as well as relatedstandardization specifications. It is expected that in the nearfuture, all the digital home devices will basically support thecapability of domain. Even now, we can see the examples ofdomain. However, to setup a domain mostly requires onlineconnection to the outside server. Besides difficulty in usingdomain-controlled devices, it is not transparent to the users.The type of domain that users really demand shall be simple,easy to use and transparent. In a practical point of view, thecurrent, complex domain mechanisms which are deployed ineach vendor or standardization organization respectively doesnot allow a user to freely share/use their contents in his or herdevices environment. It is because the domains deployed withinthe user environment are not interoperable. Therefore we con-clude that the interoperability problem of protection schemescan be reduced to the interoperability problem of domains.

V. OPEN PROBLEMS

To achieve service and content protection, both efficient andpersistent, two major problems need to be further considered:transcodable encryption and obfuscation.

1) Transcodable Encryption: Transcoding issues becomemore critical when the target content is protected via encryptionin the aspects of performance and security. A broadcast signalcan travel via different delivery media. For example, the broad-cast may be carried on a satellite and then conveyed into somehomes via a cable system. In such cases it is often desirable tochange the entitlement control at the media boundary withoutneeding to descramble and rescramble completely. (This ispossible with the use of the Common Scrambling Algorithm.)However, this method may present a security risk because oneCA system operator would have to present the control word toanother CA system operator inside the transcontrol equipment.As another example, a broadcast signal can travel via set-topbox to portable devices, where decryption of the content,transcoding, then encryption of the content usually be donein this order. However, the problem is whether to guaranteethe real-time transcoding, that is, decryption of the protectedcontent re-encoding of the decrypted content in the end userenvironment where low-capability machines comprise, withoutrevealing the encryption key to the transcoding entity (sites,nodes, etc.) and with no considerable performance overhead onthe end user’s real-time consumption of the content. Designingtranscodable encryption remains an open issue, and is veryimportant.

2) Obfuscation: Attackers can analyse program semanticsby executing programs step by step using software tools in-cluding debuggers. They can also analyse them by transforminga machine language into an assembler language or other human-friendly languages. Code obfuscation technology is one of thecountermeasures against these attacks. Code obfuscation can beused to protect SCP client programs. Code obfuscator takes aprogram as input and produces a new program that has the same


functionality as the input program but is unintelligible to at-tackers as well as users. Until now, obfuscation has been consid-ered to be impossible satisfying the “virtual black box” property,that is, anything one can efficiently compute from the obfus-cated program, one should be able to efficiently compute givenjust oracle access to the program, under the general complex-theoretical assumption of existence of one-way functions [65],a function which is easy to compute, but hard to invert. That is,there is no general obfuscation method that can obfuscate anyprogram. Recently, it has also been shown that highly antici-pated application areas of obfuscation, such as secure encryp-tion and digital signature cannot be obfuscated [66]. However,the above results have implications only in the general sensethat general purpose obfuscators do not exist. We cannot denythe possibility of obfuscation methods which may be applicablein some restricted classes of algorithms. For example, Canetti[46] and Wee [47] showed, under specific complexity assump-tions, how to obfuscate the particular class of point functions,which consists of all Boolean functions of the formif and only if . Further research is being directed to checkthe possibility of obfuscation under specific situations.

VI. CONCLUSION

This paper presented an in-depth discussion of the securityissues and requirements for protection of content and servicefor IPTV. Content and service protection for IPTV raises nu-merous important security issues. Some of them can be ad-dressed with the current existing technologies or combinationsthereof. Others require further research. The most distinctivefeature of content and service protection for IPTV is that var-ious kinds of security mechanisms are integrated on the IPTVsignal receiving side as well as on the head-end side. The featureposes both opportunities and challenges for security. We intendthis paper to be a reference that establishes comprehensive andpractical security architectures for large-scale content and ser-vice protection system for IPTV.

REFERENCES

[1] Gartner Group, “An Introduction to IPTV (Television via Internet Pro-tocol),” Oct. 2005.

[2] “Part II. Section 3, Service security and content protection,” in ITU-TFG Proceedings, Feb. 2008.

[3] B. Rosenblatt, B. Trippe, and S. Mooney, Digital Rights Manage-ment—Business and Technology. New York: M&T Books, 2002.

[4] “Interoperable DRM Platform Specification Version 3.2,” DMP (Dig-ital Media Project), Oct. 2008.

[5] “OMA DRM Specification Version 2.0,” OMA (Open Mobile Al-liance), Mar. 2006.

[6] MPEG-21, [Online]. Available: http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm

[7] “Coral Consortium Core Architecture Overview Version 3.0,” CoralConsortium, Jun. 2006.

[8] Digital Video Broadcasting (DVB) Head-end implementation of DVBSimulcrypt, ETSI TS 103 197 v1.4.1, Dec. 2004.

[9] DVB-CI Common Interface Specification for Conditional Access andother Digital Video Broadcasting Decoder Applications, CENELEC,EN 50221, 1997.

[10] Conditional Access System for Terrestrial Broadcast, Revision A,ATSC Standard, 2004.

[11] IP Datacast over DVB-H: Service Purchase and Protection (SPP),ETSI TS 102 474, Dec. 2005.

[12] Service and Content Protection for Mobile Broadcast Services, Version1.0, OMA (Open Mobile Alliance), Nov. 2007.

[13] S. Kent and R. Atkinson, Security Architecture for the Internet ProtocolIETF RFC 2401, Nov. 1998.

[14] R. Pereira and R. Adams, The ESP CBC-Mode Cipher Algorithms IETFRFC 2451, Nov. 1998.

[15] R. Glenn, S. Kelly, and S. Frankel, The AES-CBC Cipher Algorithmand Its Use With IPsec IETF RFC 3602, Sep. 2003.

[16] H. Krawczyk, M. Bellare, and R. Canetti, HMAC: Keyed-Hashing forMessage Authentication IETF RFC 2104, Feb. 1997.

[17] C. Madson and R. Glenn, The Use of HMAC-SHA-1-96 Within ESPand AH IETF RFC 2404, Nov. 1998.

[18] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, TheSecure Real-time Transport Protocol (SRTP) IETF RFC 3711, Mar.2004.

[19] Internet Streaming Media Alliance Encryption and AuthenticationSpecification Version 1.0, ISMA, Feb. 2004.

[20] Internet Streaming Media Alliance Implementation Specification Ver-sion 1.0, ISMA, Aug. 2001.

[21] H. Lipmaa, P. Rogaway, and D. Wagner, “CTR-Mode Encryption,”[Online]. Available: http://csrc.nist.gov/encryption/modes/workshop1/papers/lipmaa-ctr.pdf

[22] Digital Transmission Content Protection Specification Volume 1, Revi-sion 1.4, 5C Feb. 2005.

[23] CPPM/CPRM Version 1.0, 4C Entity, 2003.[24] High-bandwidth Digital Content Protection System Revision 1.3, Dig-

ital Content Protection LLC, Dec. 2006.[25] DCAS Specifications: Host Device 2.5 Core Functional Requirements,

OpenCable, OC-SPHOST2.5-CFR-D03-061122.[26] DVB-CPCM Bluebook A94r1, DVB Content Protection and Copy Man-

agement, DVB (Digital Video Broadcasting), 2007.[27] Content Protection and Copy Management Specification: CPCM

Authorised Domain Management, DVB (Digital Video Broadcasting),2007.

[28] B.C. Popescu, F.L.A.J. Kamperman, B. Crispo, and A.S. Tanenbaum,“A DRM security architecture for home networks,” in Proc. 4th ACMWorkshop on Digital Rights Management, 2004.

[29] T.S. Messerges and E.A. Dabbish, “Digital rights management in a 3Gmobile phone and beyond,” in Proc. 3rd ACM Workshop on DigitalRights Management, 2003.

[30] IBM, “xCP: eXtensible Content Protection,” Jul. 2003.[31] G.A. Spanos and T.B. Maples, “Performance study of a selective en-

cryption scheme for the security of networked, real-time video,” inProc. 4th International Conference on Computer Communications andNetworks, Sep. 1995.

[32] X. Liu and A. Eskicioglu, “Selective encryption of multimedia con-tent in distributed networks: challenges and new directions,” in Proc.IASTED Communications, Internet & Information Technology (CIIT),Nov. 2003.

[33] S. Hwang, J. Kim, D. Nam, and K. Yoon, “Protection of MPEG-2 mul-ticast streaming in IP set-top box environment,” ETRI Journal, vol. 27,no. 5, Oct. 2005.

[34] M. Arnold, M. Schmucker, and S.D. Wolthusen, Techniques and Ap-plications of Digital Watermarking and Content Protection. Boston,MA: Artech House, 2003.

[35] B. Chen and G.W. Wornell, “Quantization index modulation: a class ofprovably good methods for digital watermarking and information em-bedding,” IEEE Trans. Information Theory, vol. 47, no. 4, May 2001.

[36] I.J. Cox, M.L. Miller, and J.A. Bloom, Digital Watermarking. SanFrancisco, CA: Morgan Kaufmann, 2001.

[37] M. Wu and B. Liu, “Data hiding in image and video. I. Fundamentalissues and solutions,” IEEE Trans. Image Processing, vol. 12, no. 6,Jun. 2003.

[38] C. Collberg, C. Thomborson, and D. Low, “Manufacturing cheap,resilient, and stealthy opaque constructs,” in Proc. 25th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages,1998.

[39] C. Collberg and C. Thomborson, “Software watermarking: models anddynamic embeddings,” in Proc. 26th ACM SIGPLAN-SIGACT Sympo-sium on Principles of Programming Languages, 2000.

[40] R. L. Davidson and N. Myhrvold, “Method and System for Gener-ating and Auditing a Signature for a Computer Program,” US Patent5,559,884, 1996.

[41] J. P. Stern, G. Hachez, F. Koeune, and J. Quisquater, “Robust ObjectWatermarking: Applications to Code,” in Proc. Information Hiding,1999.

[42] A. Monden, H. Iida, K. Matsumoto, K. Inoue, and K. Torii, “A prac-tical method for watermarking Java programs,” in Proc. 24th ComputerSoftware and Applications Conference, 2000.


[43] R. Venkatesan, V. Vazirani, and S. Sinha, “A graph theoretic approachto software watermarking,” in Proc. 4th International InformationHiding Workshop, 2001.

[44] C. Thomborson, J. Nagra, R. Somaraju, and C. He, “Tamper-proofingsoftware watermarks,” in Proc. 2nd Australasian Information SecurityWorkshop, 2004.

[45] D. Boneh and J. Shaw, “Collusion-secure fingerprinting for digitaldata,” IEEE Trans. Information Theory, vol. 44, no. 5, Sep. 1998.

[46] R. Canetti, “Towards realizing random oracles: hash functions that hideall partial information,” in Proc. Advances in Cryptology—CRYPTO,1997.

[47] H. Wee, “On obfuscating point functions,” in Proc. 37th annual ACMSymposium on Theory of Computing, 2005.

[48] Open Digital Rights Language, Version 1.1, The ODRL Initiative, Aug.2002.

[49] ContentGuard, “XrML (eXtensible rights Markup Language),” Nov.2001.

[50] Xerox Corporation, “The Digital Property Rights Language,” 1998.[51] R. Safavi-Naini, N.P. Sheppard, and T. Uehara, “Import/export in dig-

ital rights management,” in Proc. ACM Workshop on Digital RightsManagement, 2004.

[52] “Content Protection and Copy Management Specification: Usage StateInformation (USI),” DVB (Digital Video Broadcasting), 2007.

[53] DOI [Online]. Available: http://www.doi.org[54] URI [Online]. Available: http://www.ietf.org/rfc/rfc2396.txt[55] MPEG-21 DII (Digital Item Identification), ISO/IEC 21000-3 FDIS,

Jul. 2005.[56] INDECS [Online]. Available: http://www.indecs.org[57] MPEG-21 DID (Digital Item Declaration), ISO/IEC 21000-2 FDIS,

May 2002.[58] MPEG-21 RDD (Rights Data Dictionary), Ad Hoc Group on Editing

the RDD (N5191), Oct. 2002.[59] Dublin Core [Online]. Available: http://www.dublincore.org

[60] MPEG-7 Multimedia Description Schemes, ISO/IEC 15938-5, Mar.2001.

[61] OMA DRM v2.0 Extensions for Broadcast Support, OMA (Open Mo-bile Alliance), Apr. 2006.

[62] 3G Security; Security of Multimedia Broadcast/Multicast Service (Re-lease 8), Technical Specification Group Services and System Aspects,3GPP 33.246, 3rd Generation Partnership Project, Mar. 2008, .

[63] Broadcast-Multicast Service Security Framework, Technical Specifi-cation 3GPP2 S.S0083-A, 3rd Generation Partnership Project 2, Aug.2004.

[64] Information Technology Coding of audio visual objects—Part 12: ISObase media file format, ISO/IEC 14496-12, 2005.

[65] B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S.Vadhan, and K. Yang, “On the (im)possibility of obfuscating pro-grams,” in Proc. Advances in Cryptology—CRYPTO, 2001.

[66] S. Goldwasser and Y. Tauman Kalai, “On the impossibility of obfus-cation with auxiliary inputs,” in Proc. 46th IEEE Symposium on Foun-dations of Computer Science (FOCS), 2005.

Seong Oun Hwang received his BS degree in math-ematics in 1993 from Seoul National University, hisM.S. degree in computer and communications engi-neering in 1998 from Pohang University of Scienceand Technology, and his Ph.D. degree in computerscience from Korea Advanced Institute of Scienceand Technology. He worked as a software engineerat LG-CNS Systems, Inc. from 1994 to 1996. Heworked as a senior researcher at Electronics andTelecommunications Research Institute (ETRI) from1998 to 2007. Since 2008, he has been working as

an assistant professor with the Department of Computer and Information Com-munication Engineering of Hongik University, Korea. His research interestsinclude cryptographic algorithms, protocols, and applications.

content and service protection for iptv

Documents