Valer Bocan Scalable and Secure Archtecture for Dgtal Content Dstrbuton Mha Fagadar-Cosma Department of Computer Scence and Engneerng Informaton Technology Department Poltehnca Unversty of Tmsoara Alcatel Romana 2 V. Parvan Ave., 300223 Tmsoara, ROMANIA 9 Gh. Lazar Ave., 300081 Tmsoara, ROMANIA vbocan@dataman.ro mha.fagadar@alcatel.ro Abstract: Ths paper descrbes a scalable and secure archtecture for dgtal content dstrbuton. Our archtecture enables secure cooperaton between content provders whch share dstrbuton rghts, allowng a greater flexblty n realworld scenaros. Furthermore, the new archtecture s hghly scalable as t enables content provders to smultaneously servce several clents who request the same content. Index Terms scalable DRM, dgtal content, dstrbuton, redstrbuton, secure broadcast, cryptography, secret splttng. I. INTRODUCTION Dgtal content dstrbuton has become a wdely dscussed topc n the past years, due to the ncreasng popularty of the Internet and of the personal devces capable of playng dgtal multmeda content. More and more provders offer ther customers the possblty to access, for a fee, large on-lne databases of multmeda content whch they can download on ther personal devces. Due to ntegraton of technologes lke Bluetooth or W- F, personal devces have become capable of sharng nformaton among them n a pont-to-pont manner. Ths has opened the way to dgtal content redstrbuton, a process whch generates revenue loss by excludng the content provder from the data transfer. To preserve the dgtal content from llegal copyng and unauthorzed dstrbuton and to ensure that copyrght laws are respected, content provders have searched for new ways of mplementng secure dstrbuton systems, based on Dgtal Rghts Management (DRM) polces. The greatest challenge posed to such a system s to ensure that these polces are effectve even after the customer came nto the possesson of the dgtal content, especally when he attempts to redstrbute t to another user. The current approach to the above-mentoned problem has been to ntroduce the noton of complant devces, whch, by ther desgn, guarantee to respect the DRM polces assocated wth the multmeda content they are playng. For example, a complant devce wll refuse to share ts contents wth a non-complant devce, or to redstrbute the multmeda content to another complant devce f the assocated DRM polcy forbds t to do so. Systems whch allow dgtal content redstrbuton by enforcng the DRM polces at clent level on peer-to-peer networks have already been proposed [1]. However, they are not scalable, and present a vulnerablty to DoS attacks, whch may render them noperable. These systems also rely on the fact that each content provder has all the necessary rghts to dstrbute the multmeda content to ts customers, whch may not always be true n real stuatons. Such rghts may be dstrbuted among several content provders. In the present paper we propose a scalable dgtal content dstrbuton system, whch reles on secure broadcast for dstrbutng the dgtal content to several clents smultaneously. Thus the sever load s decreased consderably, whle mantanng the same degree of securty as n normal pont-to-pont connectons. We also propose a mechansm to remove the lmtaton of a sngle content provder whch has all the rghts over the dgtal content. In our archtecture, for a dgtal content, there may be several content provders whch share the dstrbuton rghts over that content, and a common consent s requred to dstrbute t. The paper s organzed n sx sectons, as follows. In Secton II we present the system archtecture and the partes nvolved n the dgtal content dstrbuton and redstrbuton. Secton III focuses on the cryptographc technques used to secure the communcaton between the system components. Secton IV descrbes the scalable dstrbuton of dgtal content n both cases: provder to clent and clent to clent, and how the technques presented n Secton III apply to our partcular case. Secton V analyzes the possble threats to ths system and fnally, Secton VI presents the advantages of the proposed soluton and draws the fnal conclusons. II. SYSTEM ARCHITECTURE The system archtecture, presented n Fg. 1, contans two major parts: The authorty and content dstrbuton part composed of one Master Content Provder and several authorzed Content Provders; The consumer network composed of Clents or Content Proxes. The partes nvolved n the dgtal content dstrbuton scheme are as follows:
A. Content Provders Content provders (CPs) are partes whch share the rghts to dstrbute the dgtal content to the consumer network. A consumer whch desres to receve the dgtal content wll ssue a request to a content provder whch, n turn wll subject the request to the approval of all the CPs whch share the dstrbuton rghts of the dgtal content. If all CPs approve the request, then the content provder wll send the dgtal content to the clent, otherwse t wll reject the request. redstrbute t. The requrements whch must be fulflled by such a complant devce are outlned n the Trusted Platform Module (TPM) specfcatons [4]. Each complant devce s endowed at manufacturng tme wth a par of keys: a publc key and a prvate key, whch t uses when exchangng nformaton wth a CP or another clent. The redstrbuton process, llustrated n Fg. 1 between clents A and D, takes place n accordance to the DRM polces assocated wth the content (e.g. the content may be redstrbuted only a lmted number of tmes and to a lmted number of complant devces). If DRM polces are not respected by the clent, the CP may revoke ts redstrbuton rghts, by usng the devce revocaton mechansm presented n [1]. D. Content Proxes Content proxes dfferentate from clents n the way that they are actng as relays between the CP and other customers. Any clent may become a content proxy f he desres to do so, by sgnalng ths ntent to the CP. Snce the multmeda content s encrypted, the proxy wll not be able to render t f not addressed to t drectly, but s able to forward the content to ts legtmate destnaton. In Fg. 1, Clent C has the role of content proxy and t dstrbutes the data to clents D and E, through secure broadcast. By makng use of content proxes, a CP can reduce ts server load sgnfcantly, snce clent requests for dgtal content can be servced by the proxy, wthout the nvolvement of content provders. The CP constantly montors proxy actvtes to make sure that they are n accordance wth the DRM polces. Fg. 1. The content dstrbuton system archtecture A sngle pece of dgtal content wll be broadcast to the clents who request t n a gven tme frame. Ths technque greatly reduces the load on the server by servcng several clents at a tme. B. Master Content Provder The Master Content Provder (MCP) represents the organzaton whch controls the actvty of all content provders (CP), and t s nvolved ndrectly n the content dstrbuton process. It can be regarded as the authorty whch supervses the request approval process between the content provders and generates sesson keys for ther actvtes. C. Clents Clents are complant devces whch have the rght to play the multmeda content receved from a content provder, and may optonally purchase the rghts to III. CRYPTOGRAPHIC TECHNIQUES Data transfers between the partes nvolved n the proposed content dstrbuton scheme take place on secure channels, protected by a seres of cryptographc methods, as follows: the cooperaton between the CPs s mplemented by usng the secret splttng technque [2] whle the CP to clent and proxy-to-clent data transfers are based on secure broadcast wth secure locks [3] generated usng the Chnese Remander Theorem [5]. A. Secret Splttng Technque As we prevously stated, the content provders may share dstrbuton rghts, n whch case they must all approve the clent requests. Therefore, the CPs must cooperate for each request approval, n a secure manner. The most secure way to make the CPs cooperate s to share a secret among them, by usng the secret splttng technque [2]. Ths way, no content provder can obtan the secret wthout the help of the other CPs wth whom t shares that secret.
Consderng a secret message M of length m and a group of n secret sharers, desgnated P 1, P 2,..., P n, the secret can be splt among the n sharers as follows: 1) Frst, a number of n-1 random bt strngs of length m, R 1, R 2,..., R n-1 are generated. 2) The message M s encrypted, resultng the secret S Κ. = M R1 R2 Rn 1 3) The secret S s dstrbuted to P 1, R 1 s dstrbuted to P 2, R 2 to P 3 and so on, up to R n-1 whch s dstrbuted to P n. It s obvous that the only way to obtan the secret M s by XOR-ng together the peces dstrbuted among the secret sharers. The sharers themselves need not even know who receved S, and who receved the random strngs R. Ths makes the secret splttng technque absolutely secure. In our case, consderng that the dstrbuton scheme contans one MCP and a number of n CPs: CP 1, CP 2,..., CP n, whch share the dstrbuton rghts for the dgtal content, the secret splttng technque works as follows: 1) CP receves a clent request. 2) If CP accepts the request, t asks the MCP, whch s the trusted authorty, to create and dstrbute a secret message M among all the CPs. 3) The MCP generates the secret message M, known only to hmself, splts t n n peces, and shares t among all CPs, by usng the secret sharng technque. 4) CP forwards the clent request to all the other CPs. 5) If a CP agrees to the clent request, t wll share ts part of the secret to CP, otherwse t wll send an empty strng of bytes nstead. 6) Based on the answers from the rest of the secret sharers, CP wll attempt to reconstruct the message M, whch wll be sent to the MCP for valdaton. Only f all the other CPs agreed wth the requests, CP wll be able to reconstruct the message M. 7) The MCP wll compare the message decrypted by CP to the orgnal message M, and f they match, t wll authorze CP to dstrbute the dgtal content to the clent, otherwse t wll nstruct t to reject the request. B. Usng the Chnese Remnder Theorem to generate secure locks A prevous research on dgtal content dstrbuton [1] requred that for each request the CP encrypts the content usng the publc key of the clent whch made the request. A number of n clents requestng content from the CP wll requre n content encryptons, even f the content may be the same for all clents. Ths places a serous burden on the system that servces ncomng requests and therefore represents a scalablty lmtaton. In order to reduce the server load, we propose that the CP use secure broadcastng technques to send the data to all clents whch requested t. In ths case, the dgtal content s encrypted only once, usng an encryptng sesson key known only to the CP, and sent along wth a decryptng sesson key to the clents. To make sure that only legtmate clents can obtan the decryptng key, a secure lock s needed to protect t. The lock can be removed only by the legtmate clents and s generated by applyng a technque known as the Chnese Remander Theorem (CRT) [3]: Let C be a group of n clents C 1, C 2,..., C n servced by a CP, each havng a par of keys e (secret) and d (publc), and N 1, N 2,..., N n a set of n postve ntegers that are mutually prme and publcly known n the system. From the group C, a subset of k clents (k 2) request the same dgtal content from the CP. If we furthermore consder a set of k postve ntegers R 1, R 2,..., R k, the CRT theorem states that the system of congruences: X R1 (mod N1) X R2(mod N 2 ) Λ X R k (mod N k ) has a common soluton X, gven by equaton (2): where: = 1 (1) k L X = ( R f )mod L (2) N L 1 f mod N (3) N k wth L beng defned as N. = For our proposed scheme, the CP wll generate a par of sesson keys, e s and d S, and encrypt the dgtal content only once, usng e S. The CP wll also generate the R 1, R 2,..., R k numbers by encodng the decryptng sesson key d S wth the publc encryptng key e of each requester, as follows: R = Enc d ). e ( S The secure lock X s obtaned by solvng the equaton system (1), and sent to the clents along wth the encrypted dgtal content. Each clent from the group whch requested the dgtal content can obtan R from the receved lock X, accordng to equaton system (1), and by decryptng t wth ts prvate key d, can obtan d S. Once a clent has d S, t can decrypt the multmeda content and use t accordng to ts assocated DRM polcy. From the technque descrbed above, t can be seen that the lock cannot be broken by llegtmate clents. Even f such a clent obtans a remander R, t cannot extract d S, as t does not posses the prvate key d of the legtmate clent. Therefore, ths method s secure.
IV. SCALABLE DISTRIBUTION OF DIGITAL CONTENT The content dstrbuton process can be splt nto two parts: The content provder CP dstrbutes the content and ts assocated lcenses to clents (C 1 ) The clent (C 1 ) redstrbutes the content to another clent (C 2 ). Let s ntroduce some notatons: e A /d A the publc/prvate key par of entty A [D]e A data D encrypted under publc key of A [D]d A data D sgned wth the prvate key of A [D] K data D encrypted usng a symmetrc key K h(d) a collson-free hash functon h appled on data D A. Content Provder (CP) dstrbutes content to clents In ths part, the content provder (CP 1 ) dstrbutes the dgtal content M and assocated rghts R to the clents (C ) wth permsson from other content provders (CP 2,, CP n ) and under the supervson of the master content provder (MCP). (1) C 1, C 2,, C n CP 1 : request content (2) C 1, C 2,, C n CP 1 : mutual authentcaton (3) CP 1 CP 2,, CP n, MCP: agreement upon dstrbuton rghts (4) C 1, C 2,, C n CP 1 : payment (optonal) (5) CP 1 C 1, C 2,, C n : [M] K, [K] es, X, η, δ, Λ The content provder wats for ncomng requests and servces them at certan ntervals. Smlar requests are grouped together n step (1) and servced n the same tme n order the soluton to scale by decreasng the server load. In step (2), the content provder and the clents authentcate each other. Unlke the archtecture descrbed n [1], we do not perform payment at ths stage as the content provder that receved the requests s not yet authorzed by the peers to dstrbute the content. In step (3), the content provders agree upon authorzng the content provder who receved the requests and n step (4) the payment s performed. In step (5), the content provder generates the secret lock X, encrypts the content M wth a one-tme symmetrc key K, encrypts K wth the sesson key e S and then sends the encrypted content along wth the lock X, rghts η, metadata δ and the content lcense Λ. The rghts η s a quantty that descrbes how the content s to be handled by complant devces and the metadata δ assocated wth the content (name of the artst, the album, the song ttle, bt rate, etc.). The content lcense Λ s defned as: Λ = [h(m, η, δ, X)] dcp The purpose of Λ s to certfy that the clent has been granted rghts η wth respect to content M. Rghts η can be represented usng authorzaton and access polcy languages such as XACML [6] and XrML [7]. The great advantage of our archtecture s that t s hghly scalable. When certan content s hghly demanded, several dfferent clents may request t almost smultaneously. The content provder wats for a short tme so that several requests accumulate, and then wth a sngle encrypton operaton t servces all clents. B. Clents redstrbute content The rghts η orgnally granted by the content provder may allow the clent C 1 to redstrbute the content to another clent C 2, followng the protocol below (smlar to [1]): (1) C 2 C 1 : request content (2) C 2 C 1 : mutual authentcaton (3) C 1 C 2 : [M] K, [K ] ec2, η, η, δ, Λ, Λ (4) C 2 C 1 : check δ, payment (optonal) (5) C 2 C 1 : φ C 2 starts the transacton n step (1) by requestng a partcular content tem. In step (2), the two partes authentcate each other usng ther publc/prvate key pars. If the authentcaton s successful, C 1 decrypts the content of the requested tem, generates a temporary symmetrc key K and encrypts the content wth ths key. The K key s then encrypted wth C 2 s publc key. C 1 then sends the new encrypted content, the sesson key K encrypted wth C 2 s publc key, the orgnal rghts η and the new rghts η granted to C 2. Also, C 1 sends the orgnal lcense Λ and the new lcense Λ, defned as follows: Λ = [h(e 1, e 2, M, η, δ, X)] dc1 In step (4), C 2 verfes C 1 s sgnature on the new lcense Λ and valdates η and M usng the orgnal Λ lcense. C 2 also makes sure that the η lcense can be derved from η and also checks δ for the type of content beng dstrbuted. If all checks succeed, C 2 approves the transacton n step (5), sendng C 1 a recept φ, defned as: φ = [h(e C1, e CP, [M] K, δ, η ] dc2 The recept φ represents an acknowledgement from C 2 that t receved the content M wth the rghts η. C. Content dstrbuton and relayng schema In ths secton we provde a hgh level schematc of the content dstrbuton archtecture, as llustrated n Fg. 2:
6) The proxy wll forward the encrypted message to each of the requestng clents. If an llegtmate clent requests ths message, t wll not be able to use t due to the protecton provded by the secure broadcast protocol. Fg. 2. Scalable dstrbuton of dgtal content 1) A content provder CP receves, n a gven tme frame a number of N requests (marked wth REQ n Fg. 2) for the same dgtal content. The CP wll subject these requests to the approval of the other CPs whch share the rghts over that dgtal content, by usng the secret splttng technque presented n Secton III. If the requests are granted, CP wll obtan a unque par <e S, d S > of sesson keys from the MCP. 2) The CP creates the sent-out message as descrbed n the prevous paragraph then sends t to all N clents who requested t, usng the secure broadcast wth secure lock method (SBC) [3] descrbed n Secton III. When a clent receves the message, t wll send an acknowledgement (ACK) message to the CP. 3) The CP checks f all N clents receved the message. If there are clents who responded wth a NAK (n our case clents N-1 and N) or when the server s under hgh load, CP wll send the orgnal message to one or more regstered content proxes, and delegate the task of dstrbutng t to ths proxy (step DLG n Fg. 2). If there s a regstered proxy among the clents who successfully receved the message, the CP wll skp ths step and go drectly to step 4. 4) CP nforms the clents whch have not receved the message that the proxy selected n step 3 contans a copy of the broadcasted message. From ths pont forward, CP wll not be nvolved any more n the dstrbuton of the dgtal content. 5) The clents notfed by the CP n step 4 wll request the broadcasted message from the content proxy. As stated n prevous sectons, the proxy stores the already encrypted verson of the message n a transparent manner, and s not able to decrypt t f t s not among the legtmate recevers. V. THREATS The proposed archtecture ntroduces a number of threats, some of whch beng shared wth exstng DRM archtecture and some beng new. Whle a full dscusson on the threats on DRM systems s beyond the scope of ths paper, we wll brefly outlne them. One of the most wdespread threats s tamperng wth the complant devce or the tamper-resstant module nsde. Good tamper-resstance s dffcult to acheve [8, 9] so we can assume that securty s effectve aganst all but the most determned attacker. Cryptographc technques are hardly a threat today as attackers are smart enough to attack the weakest pont. Content redstrbuton and collaboraton between content provders are all target ponts for attackers and a whole new lot of attacks are possble: Content masqueradng durng the redstrbuton process. Ths may happen when a clent receves a lesser value content than the one requested or a proxy clent replaces the content to be further dstrbuted. Snce devces are susceptble to falure, they allow backng up the lcenses and the content to unsecured meda. Ths can lead to untrusted storage backup attacks. Crcumvented devces are able to remove the securty mechansms that protect the dgtal content and therefore they can llegally dstrbute the content. Detectng and solatng crcumvented devces s essental to the health of a DRM system. Because of the desgn f the content provder collaboraton protocol, the compromse of a sngle provder leads to total falure of the content dstrbuton. If a sngle content provder msbehaves t s very dffcult to be excluded from the decsonal process. Unlke other systems that deal wth expensve operatons (.e. publc key cryptography), our archtecture s less susceptble to denal of servce attacks as the task of dstrbutng the content can be delegated the cooperatng clents. DoS attacks are nonetheless possble so a number of ways to mtgate such threats are possble [10, 11]. VI. CONCLUSION AND FUTURE WORK Dgtal Rghts Management systems are typcally used by provders to restrct the ways consumers use the content. In ths paper we proposed an archtecture that matches close to
real-world scenaros where several content provders share the rght over a sngle pece of content. Our archtecture s hghly scalable as t enables smultaneous servcng of several clents that request the same content by usng secure broadcastng and enables clents to become proxes n order to decrease the load on the central server. Our archtecture s also capable of preservng the rghts of the dstrbuted content even when redstrbuted from clent to clent, provded that certan requrements are met on the clent devce. Currently we are workng on addng resstance to denal of servce attacks to the archtecture and devsng some gudelnes for real-world mplementaton. We are also workng on performance metrcs of the archtecture. REFERENCES [1] S. K. Nar, B. C. Popescu, C. Gamage, B. Crspo and A. S. Tanenbaum, Enablng DRM preservng Dgtal Content Redstrbuton, 7 th Internatonal IEEE Conference on E-Commerce Technology, 2005 [2] Bruce Schneer, Appled Cryptography, John Wley & Sons, 1996, pag. 70 [3] G.-H. Chou and W.-T. Chen, Secure Broadcastng Usng the Secure Lock, IEEE Trans. Software Eng., vol. 15, no. 8, pp. 929-934, August 1989. [4] Trusted Computng Group, Trusted Computng Platform Allance Man Specfcaton, October 2003, Verson 1.2, http://www.trustedcomputnggroup.org [5] Erc W. Wessten, Chnese Remander Theorem. From MathWorld - A Wolfram Web Resource, http://mathworld.wolfram.com/chneseremandertheorem.html [6] extensble Access Control Markup Language (XACML), http://www.oass-open.org/commttees/xacml [7] XrML: extensble Rghts Markup Language, http://www.xrml.org [8] R. Anderson, M. Kuhn, Tamper Resstance A Cautonary Note, Proceednggs of the 2 nd Usenx Workshop on Electronc Commerce, pages 1-11, November 1996. [9] Andrew Huang, Keepng Secrets n Hardware: the Mcrosoft XBox TM Case Study, May 2002, http://web.mt.edu/bunne/www/proj/anatak/aim-2002-008.pdf [10] Valer Bocan, Threshold Puzzles. The Evoluton of DoS-Resstant Authentcaton, CONTI 2004 - Perodca Poltehnca, Transacton on Automatc Control and Computer Scence Vol. 49 (63), 2004, ISSN 1224-600X, http://www.dataman.ro/vbocan/download/cont2004-3.pdf [11] Valer Bocan, Mha Fagadar-Cosma, Adaptve Threshold Puzzles, EUROCON 2005 - The Internatonal Conference on "Computer as a tool", Belgrade, Serba and Montenegro, http://www.dataman.ro/vbocan/download/eurocon%202005%20- %20Adaptve%20Threshold%20Puzzles.pdf