A DRM Interoperability Architecture Based on Local Conversion Bridge with Proxy Re-Cryptography

Lihao Su Weiwei Zhang Ru Zhang Jianyi Liu

Introduction

In digital contents age，conflicts always exist between copyrights protection and makingmost of the Internet to share information.Various Digital Rights Management（DMR）Standards are introduced and applied to all kinds of devices，which however gives rise to new problems such as content consumers cannot share contents between devices by just copying them from one device to another conveniently and freely.

Different DRM standards have their respective implementation details of encryption algorithm and packaging format to wrap content.Also semantic rules for rights expression language in license are diverse between different DRM standards.Without compromising these security properties，DRM Interoperability system distributes content and license in required DRM format to devices or transfers content and license from one DRM format to another between devices while keep rights consistent in the process.

Related Work and Our Design Principle

Generally，there are two types of interoperable schemes that approach device's DRM-specific requirements，one is based on distribution in which each device receives content from domainmanagers in desired format such as in[1，2]，another is based on sharing between devices to transform the content of one device's format to another's through DRM translation such as in[3，4].

Early interoperability scheme[5]approaches Digital contents transformation with neutral format.Devices translate the source's DRM-specific contents into the neutral formatwhen exporting it and then convert the received neutral format to destination's required contents formatwhen importing it.Underlying requirements in this proposal include that all devices have to agree with neutral format generation algorithm，which isweakly feasible.

Earlier proposal by[6]，downloads heterogeneous DRM components as software to extend DRM agents functionality，provides various API tomeet DRM agent's knowledge requirements for transformation between different DRMs.But license translation may spin out of control at devices'end.

Similarly，[3]transfers interoperable process to DRM agent in terminal devices，and DRM service providers only support these devices in different domainswith necessary information such as compatible Rights Object（RO）and profile.

[1]uses an DRM Interoperability agent，which employs proxy re-encryption scheme for content protection，but it only takes effect in content distribution channel from providers to end devices，so it requires content acquisition from Internet source when a new device wants to share an owned content.

[2]tries to install Trusted Platform Module（TPM）in Local Domain Manager（LDM），so content scrambling key SCK m can be securely encrypted inside TPM without software based encryption algorithm.However tamper-resistance through hardware is not economically feasible for existing PCs according to[7].

[4]provides bases and preliminaries of DRM backgrounds for our proposal，it presents a basic application of proxy re-encryption.In its content sharing scenario between end devices，proxy re-encryption diverts the workload of encrypting K m to semi-trusted proxy.Source device sends K m under its own public key to proxy to be re-encrypted into a message under destination devices'public key.But this scenario impractically assumes that exporting and importing terminal devices uses identical encryption algorithm.And their schemementions nothing about using license to constrain action of translation and re-encryption by third party.Our proposal resolves these problems by separating encryption into 2 layers，with first inside layer universally adopted by all providers，the second layer could be customized by different DRM schemes.

Above all，ourmain consideration for a secure and efficient DRM conversion scheme follows the principles as below：

（1）Guarantee secure communication between participants through encryption.

（2）Minimize the number of participants and the amount of communication data for key exchange and re-encryption key generation.

（3）Minimize calculation requirements for end devices.

Proxy Re-encryption Algorithm Preliminary

We employ the Proxy Re-encryption scheme raised by Improved proxy re-encryption schemes[8].

Definitions：

ABilinear Map is amap e： G 1 × → G 2 in which the following properties are satisfied：

（1）G 1 and G 2 are groups of the same prime order q；

（2）for all a ， b ∈ Z q ， g ∈ G 1 ， h ∈ ，then e （ g a ， h b ） =e （ g ， h ） ab is efficiently computable；

（3）themap is non-degenerate，i.e.if g generates G 1 and h generates ，then e （ g ， h ）generates G 2 ；

There are two levels of encryption in proxy re-cryptography.

The level1 encryption algorithm encryptsmessages under A's public key so that the encrypted message can only be decrypted under A's private key.

The level2 encryption algorithm encryptsmessages under A's public key while the encrypted message can be re-encrypted with rk A→B so that it can be decrypted under B's private key.

For global system parameterswhich all entities share，there are random generators g∈G 1 and Z=e（g，g）∈G 2 ，in which G 1 and G 2 are two groups of the same prime order with a bilinear map →G 2 .So Re-cryptography can be divided in the following setting and functions：

（1）Alice has private key and public key ；Bob has private key（ b 1 ， b 2 ， g b 2 ），public key（ Z b 1 ， Z b 2 ）and delegatee key（ g b 1 ）.

（2）Re-Encryption Key（Alice to Bob）Generation： is generated by Alice，who finds out Bob's public key g b 1 as delegatee key and invokes her own private key a 2 as a delegator key.

（3）First Level Encryption with Alice's public key：Message M is encrypted to get（ Z a 1 k ， M · Z k ），In which and K is randomly generated by Sender.

（4）First level Decryption with Alice's private key：

（5）Second level Encryption with Alice's public key：（ g k ， M · Z a 2 k ）In which M · Z a 2 k = and K is randomly generated by Sender

（6）Re-Encryption with Re-key： In which Z b 1 a 2 k =e （ g k ， g b 1 a 2 ）

（7）Re-Encryption Decryption with Bob's private key：

System Architecture

In the following section，an elaborate introduction of our proposed system will be presented and functions of each component in the architecture will be explained.For content flow to be published and purchased freely in the digital contentmarket and consumed conveniently among devices，the complete DRM system involves two processes，as is illustrated in Fig.1：1.Content purchase and distribution process；2.Content sharing process.

Content encryption key re-encryption steps. Our paper presumes that some contents have been purchased from providers.Hence we will focusmainly on content sharing process.

Here is a step layout to explain how our protocol works.The following descriptive steps only illustrates protection for content encryption key K m .

Note that AE 1，2 （M，K）means level 1 and level 2 asymmetric encryption respectively and SE（M，K）means symmetric encryption ofmessage M with key K.PAC（M）means packaged message M in certain digital content file format.

Step 1：After obtaining his devices such as Device A PC and Device B mobile phone，user needs to register them in the conversion domain which belongs to a Domain Bridge Agent（DBA）.In this case，there are Devices A and B，so domain manager DBA ask for ID of A，B and notifies the Trusted DRM Interoperability Server（DIS）to look for Device A's pair of public key（ g a 0 ， g ar ）and private key（ a 0 ， a r ）and B's public key（ Z b 0 ）from theirmanufacturers.

Step 2：For the first time Device A sends a request to DBA asking for contentm's conversion，DBA connectswith DRM server and receives re-encryption key（rk）list for A from DRM server.Since DRM Server knows all devices public/private key pairs，it takes charge of generating rk pairs securely.A's list for N sessions of rk pairs comes as：

In which for every AE 1 （t i ，PK x ）（i=1，2，…，N），timeans temporary private key for destination device in every conversion session.And for each pair of session key，x in AE 1 （t i ，PK x ）stands for all devices except A，therefore g arti/a0 in ith session can be for all destination devices.

Step 3：After uploading its content m and license to Bridge，a conversion session starts.DRM bridge agent firstly extract Rights Object form and get RO m .Contained in RO m ，K mis encrypted by A's public key in second-level： AE 2 （ K m ， PK a ） = （ g a 0 k ， K m · Z ark ），in which g a 0 k = （ g a 0 ） k and K m · Z ark =K m ·（ Z ar ） k and K is randomly generated by Sender.For ith conversion from A to B，DBA picks up and re-encrypt AE 2 （ K m ， PK a ）with the calculation of e to get .

When conversion finished，DRM agent in A downloads a new License in which RO m was removed and VirtualMonotonic Counter（VMC）is decremented by one by DBA.And along with the download process，DBA sends license update notification to DRM agent to decrement its VMC to make it consistentwith new license.So A can no longer renderm.This license updatemechanism guarantees thatatanytime only one device in the conversion domain can renderm within its validation period.Then DBA generates RO m for B's License.When B logged in the conversion domain，it downloads the converted Contentm.Only B can decrypt AE 1 （ SK t ， PK b ）with its private key PK b =b 0 and get SK t = t i ，so it can further decrypt and get Km.Complete conversion steps for content and license are illustrated in Figure 2：

User operation steps. Source device user：Register（First time）→Log in→Upload（Content，License）→Convert→Download（License）

Destination device user：Register（First time）→Log in→Upload（License）→Download（License，Content）

Security Analysis and Comparison

What distinguishes our proposal to[1，2，3]is thatwe build our interoperability framework based on local third party，leaving content provider out of interoperability service so that distribution channel would be simplified without installing various DRM interfaces.This feature is our proposal's biggest advantage over[1]which incorporates multiple entities to accomplish re-encryption key issuing through 9 rounds of negotiations.Besides，[1]only applies one layer of encryption over raw contentwhich undermines system's flexibility.

The proposed rk list updatemechanism embodies our earlier design principle 2 ofminimizing the amountof communication data for key exchange and re-encryption key generation and principle 3 of transferring the translation and re-encryption burden to DIS and DBA from end device.These feature highlights our proposal in comparison with[3，4]which relies on end devices to accomplish DRM adaptation.

Time consumption for one conversion is reduced both in communication and at terminal agent side.Similar to[1]，we implement a prototype using the Proxy re-cryptography Library（PRL）[9]in Linux system.A complete re-encryption process is executed and evaluated in functions and in overall session.We compare our scheme to designated proxy re-encryption（DPRE）proposed by[1]，which multiplies an addition proxy private keyπon exponent of second level encrypted cipher text（g k ，M·Z a2πk ）and re-encrypt as e（g k ，g a2b1 ）π=Z b1a2πk to implement proxy designation.Functions that comprise thewhole re-encryption process in[3]are respectively denoted below：

gen params （）：generate domain parameters； keygen （）：generate a public/private key pair； level 1 encrypt （）：perform first-level encryption； level 2 encrypt （）：perform second-level encryption； delegate （）：generate a re-encryption key； re-encrypt （）：re-encrypta second-level encrypted message； decrypt （）：decrypt an encrypted message

Our advantage in time consumption is demonstrated in table 1：

We use gettimeofday（）to get time difference before and after a function and measure this function's duration.We deploy this testing program on Intel Core（TM）3.10 GHZ CPU and 1.98G RAM，linux Cent OS.

In the above，N represents the number of re-encryption keys in list.A complete conversion in DPRE comprises of key generation，level2 encryption，delegation，re-encryption and decryption，except that gen params（）happens once and for all.A usual complete conversion in our proposal constitutes of key generation，level 2 encryption，delegation，re-encryption and decryption，in which level 2 encryption and delegation usually takes no time due to acquisition form static rk list storage.

We notice that in the bold statistic there's a notable time consumption drop in level2 encrypt（）and re-encrypt（）in our proposal because exponential calculation withπfor proxy designation is left out.And in usual conversion sessions，level 2 encrypt（）takes no time because source content is ready in form of level 2 encrypted cipher text under source device's public key，and re-encryption key acquisition costs no time because the keys are available in rk list.

Summary and Further Considerations

Defects of our proposal lie in DRM property disclosure to Conversion Bridge，for DRM bridge agent has to know the specifications of each DRM rules and policies in order to convert RO and wrapped content.And similar to[2]our proposal assumes all content providers and DRM agents at terminal devices use a universal standard content encryption algorithm for raw content protection，this is a high demanding preliminary.

And as to the domain concept in consistence with foundation proposal in[3]，we have to consider that as new devices join a conversion domain，the complications concerning rk list update，storage andmanagementwould get severe in geometricmultiple growth，involving every end device in the domain.

And with regarding to Principle 1，actually key refreshment only takes effects in the second half of transmission from bridge to destination device.So other security measures to protect the confidentiality of K m and raw content has to be further implemented to our proposal.

Acknowledgments

Thiswork was collaboratively supported in partwith funds from

（1）Beijing Natural Science Foundation's project（90604022）（4122053）.

（2）National Natural Science Foundation's project（61003284）.

（3）Fundamental Research Funds for the Central Universities（2013RC0310）.

（4）Press Publication Major Science and Technology Engineering Project（GXTC-CZ-1015004/09）（GXTC-CZ-1015004/15-1）.

（5）National Key Technology Research and Development Program（2012BAH08B02）.

（6）National 863 Program（2012AA012606）.

References

[1]A secure and mutual-profitable DRM interoperability scheme；Lee Sangho，Park Heejin；Kim，Jong；IEEE Symposium on Computers and Communications，ISCC 2010

[2]Secure interoperable digital content distribution mechanisms in a multi-domain architecture；Win，Lei Lei；Thomas，Tony；Emmanuel，Sabu；MULTIMEDIA TOOLSAND APPLICATIONS，SEP 2012

[3]Interoperable DRM Framework for Multiple Devices Environment；Hwang，Seong Oun；Yoon，Ki Song；ETRIJOURNAL，AUG 2008.

[4]Towards a secure and interoperable DRM architecture；Taban，Gelareh；Cárdenas，Alvaro A.；Gligor，Virgil D；Proceedings of the ACM Workshop On Digital Rights Management，DRM′06.Co-located with the 13th ACM Conference on Computer and Communications Security，2006

[5]D.-W.Nam，J.-S.Lee，and J.-H.Kim，“Interlock system for DRM interoperability of streaming contents，”in Proceedings of IEEE International Symposium on Consumer Electronics 2007，ISCE 2007

[6]ISO/IEC 14496-13，“Information technology：Generic coding ofmoving pictures and associated audio information，part2：IPMP on MPEG-2 systems，”2002.

[7]Barhoush，Malek；Atwood，J.William；Requirements for enforcing digital rightsmanagement in multicast content distribution；TELECOMMUNICATION SYSTEMS，SEP 2010

[8]Improved proxy re-encryption schemes with applications to secure distributed storage Ateniese，Giuseppe；Fu，Kevin；Green，Matthew；Hohenberger，Susan；ACM Transactions on Information and System Security，2006.

[9]The JHU-MIT Proxy Re-cryptography Library，http：//spar.isi.jhu.edu/prl/. cbZe4SvaXPktTNTHQGqdQcqhRTJbVM5COz9eCMBvPee+vIkhPjPBzRIxTvlc9YeQ