Workflow description of digital rights management systems

Transcription

1 Workflow description of digital rights management systems Silvia Llorente, Eva Rodríguez and Jaime Delgado Universitat Pompeu Fabra (UPF), Departament de Tecnologia, Pg. Circumval lació 8, E Barcelona, Spain {silvia.llorente, eva.rodriguez, Abstract. Digital Rights Management (DRM) is becoming a key issue in our highly networked world. Piracy of digital goods of any kind (music, software, video) is growing day by day. In this scenario, many companies, organisations and administration-funded projects provide solutions for the implementation of digital rights management (DRM) systems. Nevertheless, although these solutions have several points in common, they are incompatible in terms of architecture and system components. This paper analyses some of these solutions, focusing on the description of their data flow, one area where common points can be found. We propose the use of workflow modelling in order to find commonalities among data flow of DRM systems, that would allow easier implementation of new ones. The selected language for performing this modelling is OWL-S (Ontology Web Language for Services). The use of an ontology language will allow us to combine workflow modelling with ontologies defining DRM concepts. 1 Introduction Many companies, organisations and projects supported by European administrations provide solutions for the implementation of digital rights management (DRM) systems. Each of them proposes its own system and architecture for the protection of digital goods in an increasingly networked environment. In this paper, we present some of these initiatives, making a distinction between the ones offered by companies and the ones offered by organisations or being a result of a project funded by an administration. Afterwards, the concept of workflow is introduced, together with process modelling. The context where these concepts are used is that of services provided by electronic means [1]. In this area, OWL-S (Ontology Web Language for Services) [2], was selected. Then, we relate the concept of workflow for the description of processes with DRM systems. In this sense, we give some preliminary ideas on the modelling of generic DRM systems, specially the underlying workflow controlling transactions in such systems. Next, we give some examples of modelling for existing DRM systems using the approach proposed. The use of an ontology language (OWL [3]) for performing the

2 modelling should allow the integration of other existing ontologies (or newly created ones), dealing with the DRM domain. Finally, we present some conclusions and future lines of research. 2 Current trends in DRM systems There are many ways of providing DRM systems. In particular, each company offering a DRM system has its own solution, usually closed and proprietary. There is also the other way around, the one related to projects, at European or national level, where the results are given to the public domain in a more or less detailed way. Nevertheless, there are some common points between the different DRM systems proposed. One of them is the use of licenses for protecting. A protected is separated from the license or licenses governing its usage. A user first accesses to a and then purchases the rights to use it and the keys to unprotect it. 2.1 DRM systems offered by companies In this section we present existing proprietary DRM technologies, some of them under development, provided by relevant companies in this area, such as Microsoft [4], RealNetworks [5] or Trymedia [6] Microsoft The DRM system [4] provided by Microsoft is tied to Microsoft Windows platforms. The main features of Microsoft DRM systems are that the resources are delivered in encrypted form, the licenses are not attached to the and usually they are also delivered in encrypted form because they contain the key to unlock the encrypted resources. The data flow in Microsoft DRM is the following. First, the owner creates a packaged file with the locked with a key. If a user wants to use the, he must request a license. Then, the license clearing house generates a license containing the key that unlocks the packaged file and this license is downloaded to the user PC. The licenses in Windows Media Rights Manager contain the rights and rules that govern the use of the digital media file and the key to unlock it. The owner is who sets these rights in order to determine which rights can be exercised against the governed. These licenses can be delivered in different ways depending on the business model being used RealNetworks The DRM that RealNetworks [5] offers shares several similarities with the Microsoft DRM system described in previous section. Real s DRM main feature is that the access authentication is performed by the RealPlayer just before the playback.

3 The data flow in Real DRM system is described next. First, the RealSystem Packager generates a secured media file (*.rms). Furthermore, it generates a globally unique identifier (GUI) and a secured key for the file that are imported into the retailer s database and the secured media file is made available to consumers. Then, users contact the retail Web server to obtain a license to play the secured media file and this server requests rights from RealSystem License Server, that generates and encrypts a license that is delivered to the trusted client. Finally, the trusted client retrieves the file. It checks its secured license database to ensure it has received the rights to play the file. Then, the secured media file is decrypted and played Trymedia Trymedia s ActiveMARK DRM System [6] was designed specifically for decentralised networks, such as P2P exchanges or . It follows the idea of separating and licenses like the DRM systems described above. The main difference with the other systems is that it is not provided as a set of tools, but as a service by Trymedia Systems [6]. Trymedia s ActiveMARK DRM System has two main features; it is file independent and Player/Viewer independent. This means that it can protect any kind of and works with every player/viewer in the market. The license terms are described in Perl [7] and rights can be associated with users and devices. 2.2 DRM systems defined in projects and organisations There are organisations and projects working in defining its own DRM systems. In this section we present some of the most relevant DRM systems developed thus far Eurescom project Opera The OPERA project [8] had the objective of specifying an open DRM architecture that addressed the needs of providers, DRM system operators and customers. With respect to rights languages, the OPERA project used a proprietary rights language. The data flow in this system is described next. First, the user selects the protected in the shop he wants to purchase and he buys a license that has been already registered in the Opera Server, which is responsible for the management of the rights the users have obtained. Then, the browser requests the license to the Opera Server that generates a challenge key which is sent by SMS to the user mobile phone. Then, the user device sends this challenge key to the Opera Server that validates the user s rights to the and generates a one-time usage license. Finally, the License Server (e.g. Real DRM) sends this license to the device and the user can decrypt the protected and reproduce it.

4 2.2.2 OMA OMA DRM v1.0 [9] specification defines three DRM methods: forward-lock, combined delivery and separate delivery. The data flow for each one of the methods is specified below. In the forward-lock method, the media object is wrapped into a DRM message and delivered to the device, that can render the but not to forward it to other devices. The device does not support messages with rights objects. In the combined delivery method, a rights object and a media object is wrapped into a DRM message and delivered to the device that must enforce the rights expressions, based on Open Digital Rights Language (ODRL) [10], when consuming the. In the separate delivery method, the media object is always encrypted and converted into the DRM Content Format (DCF) [11]. The DCF object is downloaded to the device using OMA Download [12], after which the rights object is separately delivered to the device using Wireless Application Protocol (WAP) push technology as defined in Push Over The Air (OTA) Protocol specification [13]. After receiving the rights object the device may render the media object. In this method the device is allowed to super-distribute the media object, but not the rights object to another device. Then, the receiving device must acquire rights for the media object from the rights issuing service. The main features and functionalities that OMA DRM v2.0 [14] offers are the concept of domain, a group of devices (owned by a user) that will be allowed to share rights objects, and the possibility of super-distribution. This system will be able to bind the rights to the user identity, will support downloading and streaming and will have better security based on public key infrastructure. The data flow in OMA DRM 2.0 is described below. First the user browses to a web site and downloads the media object. Then, the issuer transfers the encryption key to the rights issuer. During the consumer purchase transaction, the rights issuer establishes trust with the user device and delivers the rights object to it. Finally, the user can reproduce the media object, share it within his domain and super-distribute it to a friend, which has to purchase the rights object to be able to use this media object OpenSDRM Open and Secure Digital Rights Management (OpenSDRM) [15] has been developed in the MOSES (MPEG Open Security for Embedded Systems) project [16]. The data flow when the users download existing is the following. First, the user downloads protected, for example a protected song. Then, the License Server generates a license granting to that user the right to listen the song according to the conditions selected. Finally, when the user wants to listen the song, a connection between the MOSES player and the License Server is established, and the license is downloaded. Then, the protected song is decrypted using the key extracted from the license and it is finally played.

5 3 Need of harmonisation of DRM systems The existence of several initiatives in DRM systems, both commercial and non-commercial, makes difficult their wide adoption, as concepts, rules and processes controlling them have very diverse features usually incompatible. The creation of a common model for the description of DRM systems will help in the harmonisation of them. From a commercial point of view, this may not be very feasible, as each product provider wants its solution to be selected by owners (or providers) as the one to provide protected. Nevertheless, from a research point of view and having into account the ease of integration of existing DRM solutions into newly implemented systems, which may provide their own DRM solution or use one or more of the existing ones, this is clearly an interesting approach. One way to provide a common model for the description of DRM systems is the definition of common ontologies describing the different concepts, rules and processes present inside them. To do so we can take a top-down or a bottom-up approach. If we take a top-down approach, we should first define (or look for) an ontology (or group of ontologies) with general DRM concepts and then try to apply them to existing systems. If we take the bottom-up approach, then we should define each DRM system, and then try to extract the common concepts among them, in order to generate a general ontology. Moreover, inside the description of the elements of DRM systems by means of ontologies, we could find different levels of development. We already have ontologies, like IPROnto [17], that describe some aspects of DRM systems, specially general concepts (rights, actors, etc), but we probably do not have ontologies describing the lifecycle of a digital since its creation until the moment it is provided inside a DRM system. In this case, we may describe the lifecycle by identifying steps or phases forming part of it. To do so, we propose the use of workflow in order to control this lifecycle. It is explained in more detail in the next section. 4 Workflow inside DRM systems Workflow Management Coalition (WfMC) [18] provides the following definition for workflow: the automation of a business process, in whole or part, during which documents, information or asks are passed from one participant to another for action, according to a set of procedural rules. Relating this definition with DRM systems, we can describe the lifecycle of a digital as a process where digital and information (like cryptographic keys) are passed from one participant to another for action, according to a set of procedural rules. The workflow of a DRM system represents the different steps or phases through which the passes from its initial creation (or protection, if we are not the owners but the providers or protectors) to its final distribution and purchase. During the digital lifecycle, several actors, information and processes may be involved.

6 Although we have already done some work in the definition of protected lifecycle [19, 20] based on IPROnto [17], an ontology which models the domain of intellectual property rights, we would like to represent lifecycle using a different approach. This approach is based on the work previously done in the modelling of services offered by electronic means [1, 21]. We can establish some parallelism between services offered by electronic means and DRM systems, so the concepts defined for the modelling of services apply, as explained in next section. It does not mean that we forget the lessons learnt from IPROnto, as some parts of lifecycle were already described in this ontology where actors and roles were defined, but that we want to continue the work done in the DRM field from another perspective. 4.1 Modelling of services offered by electronic means In [22, 1] we presented and refined a methodology for describing services to be provided by electronic means. This methodology had several components, defining each of them different aspects of the services. One of the components of this methodology was the definition of the service workflow. To do so, we first identified the phases of the service, the users involved on each phase and the information interchanged among users participating in a phase of a service. Once this identification is done, we are able to define the service using OWL-S [2], a language built on Ontology Web Language (OWL [3]) for the definition of services [23]. Some examples of definition of services using OWL-S can be found in [1, 21]. Other languages for the definition of workflow and process modelling like XPDL [24], BPEL4WS [25] or ebxml [26] were studied during the definition of the service description methodology. DRM systems share some features with the services we have modelled with our methodology as they also involve several users, different phases and interchange of information, for instance, digital, licenses, keys, etc. 4.2 Description of DRM systems workflow Commercial and non-commercial DRM systems describe their operation in terms of phases. In order to show the feasibility of our approach, we are going to describe in a preliminary way the workflow of two of the existing DRM systems introduced in section 2. Microsoft DRM Microsoft DRM is a proprietary product based on Windows platforms [4]. In this system, the protected and licenses are separated, and a user that wants to play a protected must purchase a license. The workflow present in this system can be separated into two main phases: Content protection and purchasing. The protection phase describes the way a owner can protect its in order to permit the purchase of it in a

7 secure way. The purchasing phase describes how a final user can purchase a protected and the license associated to consume it. Figure 1 shows the protection workflow phase. In this phase, the license clearing house is referenced from protected and the proper keys to generate licenses associated to are transmitted to the corresponding license clearing house. The digital protection phase involves the two subsequent phases, protected distribution and key for license creation. They are separated because involve different users and information. Digital protection Protected distribution Key for license creation Fig. 1. Content protection phase On the other hand, figure 2 shows the purchasing workflow phase, that involves the purchasing of the protected, the purchase of the corresponding license and, finally, the use of the protected. Purchase of protected License purchase Fig. 2. Content purchasing phase Protected usage These workflows may seem very simple, as they show consecutive phases. We have to take into account that they correspond to a commercial system with limited access to its specification. Figure 3 shows the refinement of the digital protection phase in the form of a OWL-S process. In this refinement we describe the different components of the DigitalContentProtection process in terms of OWL-S inputs, outputs, conditions and effects [2].

8 Digital Key id information information License Key Seed information User Owner Digital protection informationoutput Protected digital Fig. 3. Digital protection process Figure 4 shows a fragment of the OWL-S serialisation of the DigitalContentProtection process. Several elements are common concepts in a DRM system. For this reason, they could be referenced from one or more external ontologies, that we have generically represented by the DRMconcepts entity. <process:atomicprocess rdf:id="digitalcontentprotection"> <process:hasparticipant rdf:resource="#user"/> <process:hasinput rdf:resource="#digitalcontent"/> <process:hasinput rdf:resource="#keyid"/> <process:hasinput rdf:resource="#licensekeyseed"/> <process:hasoutput rdf:resource="#protecteddigitalcontent"/> </process:atomicprocess> <process:input rdf:id="digitalcontent"> <process:parametertype rdf:resource="&drmconcepts;#content"/> </process:input> <process:input rdf:id="keyid"> <process:parametertype rdf:resource="&drmconcepts;#key"/> </process:input> <process:input rdf:id="licensekeyseed"> <process:parametertype rdf:resource="&drmconcepts;#seed"/> </process:input> <process:unconditionaloutput rdf:id="protecteddigitalcontent"> <process:parametertype rdf:resource="&drmconcepts;#protcontent"/> </process:unconditionaloutput> Fig. 4. Fragment of OWL-S serialisation of digital protection process Open Mobile Alliance (OMA) DRM phase 2 Although the specification of OMA DRM 2.0 has not been published yet, some of the scenarios that will be supported by it have been already presented [14]. Based on this example, we have done a preliminary approach of a workflow inside OMA DRM 2.0. The workflow present in this system can be also separated into two main phases: Content protection and purchasing. The protection phase describes the

9 way a owner can protect its in order to purchase it in a secure way. The purchasing phase describes how a final user can purchase a protected and the license associated to consume it. It is also considered the super-distribution, where a user can give a protected to another user, which afterwards purchases the corresponding license to access to it. Figure 5 shows the protection workflow phase. In this phase, the is encrypted and packaged into the DRM Content Format, which can be later purchased by a user. Digital protection Fig. 5. Content protection phase Protected distribution Figure 6 shows the purchasing workflow phase including super-distribution. The dotted lines represent the optional part of this workflow, that mainly refers to the super-distribution. The arrow that goes back to license purchase phase from the super-distribution of phase represents that the user that has received the super-distributed protected from another user, has to purchase the corresponding license in order to be able to use the protected. Purchase of protected License purchase Protected usage Content superdistribution Fig. 6. Content purchasing phase, including super-distribution Figure 7 shows the refinement of the super-distribution phase in the form of a OWL-S process. In this refinement we describe the different components of the

10 ContentSuperDistribution process in terms of OWL-S inputs, outputs, conditions and effects. Protected digital UserSender Purchaser information Content superdistribution informationoutput Distributed protected digital UserReceiver PurchaserFriend Fig. 7. Content super-distribution phase refinement Figure 8 shows a fragment of the OWL-S serialisation of the ContentSuperDistribution process. Several elements are common concepts in a DRM system. For this reason, they could be referenced from one or more external ontologies, that we have again represented by the DRMconcepts entity. <process:atomicprocess rdf:id="contentsuperdistribution"> <process:hasparticipant rdf:resource="#usersender"/> <process:hasparticipant rdf:resource="#userreceiver"/> <process:hasinput rdf:resource="#protecteddigitalcontent"/> <process:hasoutput rdf:resource="#distributedprotecteddigitalcontent"/> </process:atomicprocess> <process:input rdf:id="protecteddigitalcontent"> <process:parametertype rdf:resource="&drmconcepts;#protcontent"/> </process:input> <process:unconditionaloutput rdf:id="distributedprotecteddigitalcontent"> <process:parametertype rdf:resource="&drmconcepts;#protcontent"/> </process:unconditionaloutput> Fig. 8. Fragment of OWL-S serialisation of super-distribution process 5 Conclusions and future lines Digital Rights Management systems are being described and/or developed by companies, organisations and projects supported by administrations. Each of them proposes its own architecture and way of working.

11 In order to facilitate the integration among these systems (at least at a functional level), we propose the description of their workflow using a process modelling approach. The language selected to describe the processes was OWL-S (Ontology Web Language for Services), as we already used it for the description of services offered by electronic means. As OWL-S is an ontology language it allows the use of other ontologies describing concepts related to DRM or any general concept needed. The description of the processes conforming DRM systems will facilitate their understanding, the comparison between them and their possible (and desirable from a customer point of view) integration. We have started this activity by specifying existing DRM systems following our workflow approach (see section 4.2). Our next step is to develop more general workflows, based if possible on standards, like MPEG-21 [27]. The current activities we are carrying out on MPEG-21 [28, 29] and ODRL [30] are a good environment where to start with. Acknowledgements This work has been partly supported by the Spanish administration (AgentWeb project, TIC ) and is being developed within VISNET, a European Network of Excellence ( funded under the European Commission IST FP6 program. References 1 Llorente, S. and Delgado, J. Using workflow-based systems for e-services provision. Towards the knowledge society - ecommerce, ebusiness and egovernment, Kluwer Academic Publishers, ISBN October The OWL Services Coalition. OWL-S: Semantic Markup for Web Services. 3 World Wide Web Consortium (W3C). Web Ontology Language (OWL). 4 Microsoft Corporation. Architecture of Windows Media Rights Manager. May RealNetworks, Inc. Media Commerce suite. 6 Trymedia Systems. ActiveMARK Digital Rights Management. 7 Perl language. 8 EURESCOM project OPERA (1207). Public deliverables. 9 Open Mobile Alliance. Digital Rights Management - Candidate Version 1.0. October V1_ C.pdf 10 The Open Digital Rights Language Initiative. Open Digital Rights Language (ODRL) Version 1.1. August

12 11 Open Mobile Alliance. DRM Content Format Candidate Version 1.0. November V1_ C.pdf 12 Open Mobile Alliance. Generic Content Download Over The Air Specification. February OTA-v1_ C.pdf 13 Push OTA Protocol. Wireless Application Protocol. April Bushe, W. OMA Secure Content Delivery for the Mobile World. ODRL Workshop Keynote speech. April Serrao, C. et al. Open SDRM An open and secure digital rights management solution. November MPEG Open Security for Embedded Systems (MOSES) project IPROnto Workflow Management Coalition (WfMC) Delgado, J., Gallego, I., Llorente S. and García, R. Regulatory Ontologies: An Intellectual Property Rights approach. Workshop on Regulatory ontologies and the modeling of complaint regulations (WORM CoRe 2003). Lecture Notes in Computer Science (LNCS) 2889, ISBN November Delgado, J., Gallego, I., Llorente S. and García, R. IPROnto: An Ontology for Digital Rights Management. The 16th Annual Conference on Legal Knowledge and Information Systems (JURIX-03). IOS Press, ISBN December Llorente, S. and Delgado, J. Dynamic e-services for Collaborative Applications. 23rd International Conference on Distributed Computing Systems Workshops (ICDCS 2003 Workshops), IEEE Computer Society, ISBN May Llorente, S., Delgado, J. and Polo, J. A methodology for the development of workflow based distributed systems. IEEE ICT 2001 Proceedings, Vol. 2, GEOMA, ISBN June Darpa Agent Markup Language (DAML) Services (DAML-S, OWL-S) Workflow Management Coalition. XML Process Definition Language (XPDL). October _10_xpdl_ pdf 25 Business Process Execution Language for Web Services (BPEL4WS) Version 1.1. May ibm.com/developerworks/webservices/library/ws-bpel/ 26 Electronic Business using extensible Markup Language (ebxml) ISO/IEC. ISO/IEC TR Information Technology - Multimedia Framework (MPEG-21) - Part 1: Vision, Technologies and Strategy. December Rodriguez, E., Llorente, S. and Delgado, J. DMAG answer to MPEG-21 Intellectual Property Management and Protection Call for Proposals ISO/IEC JTC 1/SC 29/WG 11/M June Torres, V., Delgado, J. and Rodriguez, E. MPEG-21 DIP Core Experiments: A contribution to the implementation of DIBOs for REL ISO/IEC JTC 1/SC 29/WG 11/M June Delgado, J., Polo, J. and Prados, J. Interworking of Rights Expression Languages for Secure Music Distribution. 4th International Conference on Web Delivering of Music (Wedelmusic 2004). To be published. September 2004.