Digital Rights Management Master s thesis in Image Coding by Cristina García Valverde and Rubén Cano Collado Report nº LITH-ISY-EX-3423-2003 Date: 2003-07-15
Digital Rights Management Master s thesis in Image Coding by Cristina García Valverde and Rubén Cano Collado Report nº LITH-ISY-EX-3423-2003 Date: 2003-07-15 Supervisors: Karl-Göran Stenborg and Jacob Löfvenberg Examiner: Robert Forchheimer Linköping 2003-07-15
Avdelning, Institution Division, Department Institutionen för Systemteknik 581 83 LINKÖPING Datum Date 2003-07-15 Språk Language Svenska/Swedish X Engelska/English Rapporttyp Report category Licentiatavhandling X Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LITH-ISY-EX-3423-2003 Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version http://www.ep.liu.se/exjobb/isy/2003/3423/ Titel Title Digital Rights Management Författare Authors Cristina García Valverde and Rubén Cano Collado Sammanfattning Abstract Nowadays, one of the main issues for the enterprises that are interested in e-bussiness is to protect their Intellectual Properties (IP) against illegal uses, that is, to guarantee, thanks to the Digital Rights, that only the users which have those Digital Rights granted can enjoy such IPs. The DRM systems emerge towards this end. This thesis will study the different steps that are followed in order to develope a DRM Solution: the framework, the requirements, the identifiers and metadata (data about data) of the IP, a standard language to express the rights (<indecs> project) and the available tools to develop the DRM Solution. To conclude, we will study a practical example of Open Proposal: OpenIPMP, and we will draw the relevant conclusions. Nyckelord Keyword DRM, IP, metadata, identifiers, interoperability, persistence, <indecs> project, rights, trusted system, DOI, ODRL, XML Security Standards, XrML, OpenIPMP.
Acknowledgements We would like to thank Magnus Andrén and our supervisors Karl-Göran Stenborg and Jacob Löfvenberg for their support in the development of this thesis. We also want to thank our supervisor Robert Forchheimer who has done everything possible in order to help us.
Abstract Nowadays, one of the main issues for the enterprises that are interested in e-bussiness is to protect their Intellectual Properties (IP) against illegal uses, that is, to guarantee, thanks to the Digital Rights, that only the users which have those Digital Rights granted can enjoy such IPs. The DRM systems emerge towards this end. This thesis will study the different steps that are followed in order to develope a DRM Solution: the framework, the requirements, the identifiers and metadata (data about data) of the IP, a standard language to express the rights (<indecs> project) and the available tools to develop the DRM Solution. To conclude, we will study a practical example of Open Proposal: OpenIPMP, and we will draw the relevant conclusions.
Table of Contents 1. Introduction and Background 1 1.1. What it is and why it is needed...1 1.2. DRM: Distribution Value Chain...2 2. Digital Rights Management: Technical description 5 2.1. Architecture and Framework...5 2.1.1. Summary...5 2.1.2. Functional Architecture...6 2.1.3. Information Architecture...8 2.1.3.1. Modeling the entities...9 2.1.3.2. Identifying and describing the entities...12 2.1.3.3 Expressing rights statements...13 2.1.4. Software Application Architecture...15 2.2. Requirements...18 2.2.1. Summary...18 2.2.2. Digital Asset Management...19 2.2.3. Trusted Systems...21 2.2.4. Expression Language...23 2.2.5. Protection...24 2.2.5.1. Conditional Access Systems...26 2.2.5.2. DRM Systems...26 2.2.5.3. Software...27 2.2.5.4. Protection Technologies...28 2.2.6. Trading Architectures...43 2.3. Identification and Metadata...47 2.3.1. Summary...47 2.3.2. The relationship of Identifiers and Metadata...48 2.3.2.1. Identifiers...48 2.3.2.2. Unique identification...49 2.3.2.3. Different concepts of what an identifier is...49 2.3.3. Namespaces as a way of Managing Identifiers...50 2.3.4. Granularity...51 2.3.5. Aids to Identifier Use: Readability and Check Digits...52 2.3.6. Resolution...53 2.3.7. Persistence...53 2.3.8. DRM Identifier Implementations Require Metadata...54
2.4. The <indecs> project...55 2.4.1. Summary...55 2.4.2. Well-formed Metadata...56 2.4.3. The <indecs> initiative: an Overview...57 2.4.4 Interoperability...58 2.4.5. Types of Interoperability...58 2.4.6. The limits of Technology...60 2.4.7. Intellectual property metadata...60 2.4.8. The <indecs> Metadata Framework...61 2.4.8.1. Characteristics of the <indecs> framework...61 2.4.8.2. Principles...62 2.4.8.3. Metadata Model...63 2.4.8.4. Metadata Dictionary...64 2.4.8.5. Creating Interoperability: Mapping Metadata...65 2.4.8.6. Directory of Parties...66 2.4.8.7. Metadata Registry...67 3. DRM Implementations 69 3.1. Summary...69 3.2. Existing Languages...72 3.2.1. Open Digital Rights Language (ODRL)...72 3.2.1.1. ODRL Definition...72 3.2.1.2. ODRL Scope...73 3.2.1.3. ODRL Expression Language...74 3.2.1.4. ODRL XML Syntax...88 3.2.2. Digital Object Identifier (DOI)...89 3.2.2.1. DOI Definition...89 3.2.2.2. DOI Syntax...90 3.2.2.3. DOI System...92 3.2.2.4. DOI Explained...93 3.2.2.5. How the DOI complements DRM...95 3.2.2.6. DOI Implementation...97 3.2.3. XML Security Standars...98 3.2.3.1. XML Digital Signature...98 3.2.3.2. XML Encryption...100 3.2.3.3. Security Assertion Markup Language (SAML)...104 3.2.3.4. XML Access Control Markup Language (XACML)...107 3.2.3.5. XML Key Management Services (XKMS)...110 3.2.4. Extensible Rights Markup Language (XrML)...111 3.2.4.1. Introduction...111 3.2.4.2. XrML data model...112 3.2.4.3. XrML basic data constructs...113 3.2.4.4. Structure and organization of the language...114 3.2.4.5. System features of the language...115
4. OpenIPMP 119 4.1. Summary...119 4.2. Specifications...121 4.2.1. Technology Overview...121 4.2.2. Components...124 4.3. Download software requirements...125 4.3.1. OpenIPMP Source...125 4.3.2. Server...125 4.3.2.1. Java...125 4.3.2.2. MySQL...125 4.3.2.3. ANT...126 4.3.2.4. JBOSS...126 4.3.2.5. EJBCA...126 4.3.2.6. OSMS...127 4.3.2.7. Microsoft Visual C++...127 4.3.2.8. MPEG4IP...128 4.3.3. Client...128 4.4. Installation and Experiments...129 4.4.1. Installation...129 4.4.1.1. Server...129 4.4.1.2. Client...130 4.4.2. Experiments...131 4.4.2.1. User Registration...131 4.4.2.2. Encoding...133 4.4.2.3. Playback...135 5. Conclusion 137 Bibliography 139
List of Figures FIGURE 1.1. Distribution Value Chain...2 FIGURE 2.1. DRM Functional Architecture...7 FIGURE 2.2. Core Entities Model...10 FIGURE 2.3. Creation Structural Types: Descriptive Data...11 FIGURE 2.4. Parties model...12 FIGURE 2.5. Primary Entity Relationships: Integrated Data Model...14 FIGURE 2.6. Rights Expression Model...15 FIGURE 2.7. Generic DRM Software Application Architecture...16 FIGURE 2.8. DRM processes between Server and User...17 FIGURE 2.9. Logical Model of a Digital Asset...20 FIGURE 2.10. Encryption and decryption...29 FIGURE 2.11. Conventional Encryption...30 FIGURE 2.12. Public Key Encryption...32 FIGURE 2.13. Simple Digital Signatures...33 FIGURE 2.14. Software Security Dongles...34 FIGURE 2.15. Principle of Individual Video Watermarking...37 FIGURE 2.16. Interoperability of watermarking in the uncoded and coded domain...38 FIGURE 2.17. Broadcasting of video with individual watermark embedding at the receiver side...39 FIGURE 3.1. ODRL Foundation Model...74 FIGURE 3.2. ODRL Permission Model...76 FIGURE 3.3. ODRL Constraint Model...78 FIGURE 3.4. ODRL Requirement Model...80 FIGURE 3.5. ODRL Condition Model...81 FIGURE 3.6. ODRL Rights Holder Model...81 FIGURE 3.7. ODRL Context Model...83 FIGURE 3.8. ODRL Offer Model...83 FIGURE 3.9. ODRL Agreement Model...84 FIGURE 3.10. ODRL Revoke Model...85 FIGURE 3.11. ODRL Encryption Model...86 FIGURE 3.12. ODRL Digital Signature Model...87 FIGURE 3.13. DOI Syntax...90 FIGURE 3.14. DRM process flow...96 FIGURE 3.15. The DOI Directory...97 FIGURE 3.16. Components of an XML Signature...99 FIGURE 3.17. XML Data structure without encryption...101 FIGURE 3.18. XML Data structure fully encryted...102 FIGURE 3.19. The SAML Domain Model...104 FIGURE 3.20. SAML Request-Response Protocol...106
FIGURE 3.21. Data-flow diagram...108 FIGURE 3.22. XACML context...109 FIGURE 3.23. Relationship between XML DSig, XML Encrypt and the XML Key Management Services......110 FIGURE 3.24. XrML data model...112 FIGURE 3.25. XrML license model...113 FIGURE 3.26. XrML organization...114 FIGURE 3.27. XrML trust model...116 FIGURE 4.1. EJBCA Architecture...127 FIGURE 4.2. OpenIPMP Login...131 FIGURE 4.3. OpenIPMP Register New User...131 FIGURE 4.4. OpenIPMP Acquire Keystore...132 FIGURE 4.5. OpenIPMP Registered Content...132 FIGURE 4.6. OpenIPMP Licenses...133 FIGURE 4.7. Mp4creator command line...134 FIGURE 4.8. GUI Player...135
List of Tables TABLE 2.1. Creations: Structural Types...11 TABLE 2.2. Rights Expressions...14 TABLE 2.3. Main Iniciatives with which <indecs> has communicated...59 TABLE 2.4. Mapped in the development of the <indecs> model...65 TABLE 4.1. Standards that have been employed in OpenIPMP...121
Chapter 1 Introduction and Background 1.1. WHAT IT IS AND WHY IT IS NEEDED "Digital Rights Management (DRM) involves the description, identification, trading, protection, monitoring and tracking of all forms of rights usages over both tangible and intangible assets -both in physical and digital form- including management of Rights Holders relationships." [1]. The need of security and safe in electronic distribution of digital contents makes that Digital Rights Management (DRM) grows as an emerging and vital business concept. In its purest form, DRM provides a technology platform to allow trusted packaging, flexible distribution and managed consumption of digital content over electronic networks. DRM technology provides content owners, service providers, distributors and retailers with a safe, secure method for meeting the consumer s need for interactive, on-demand access to movies, online games, books, music, software and propietary data (virtually any type of digital media). It is important to note that DRM is the digital management of rights and not the management of digital rights. That is, DRM manages all rights, not only the rights applicable to permissions over digital content. In order to find solutions to digital piracy, technology companies have spent hundreds of millions of dollars and thousands of engineering hours.there is not single solution that will solve all threats of piracy in all circumstances. Developing these technologies involves complex engineering efforts and it is the best interest for all content industries to work cooperatively. 1
1.2. DRM: DISTRIBUTION VALUE CHAIN The objectives for managing content rights in the traditional media world include: protecting the content and avoiding piracy, enabling revenue through outright purchase or licensing, reinforcing traditional media brands and learning more about company s audience. This is so difficult to get in the digital world. Content creation, packaging and distribution have new meanings in the Internet economy. Content conversion, digitization, compression and storage technologies have created new oportunities and efficiencies, for media and information, to be archived, repackaged and redistributed through electronic channels (e.g., the Internet, extranets, cable, terrestrial broadcasts or satellites). As content becomes more widely available in digital form, it becomes even easier to distribute, share, copy and alter if it is improperly meta-tagged (unique identifying tags related to media format, creator, usage and distribution rules) and encrypted throughout the digital distribution value chain. This brings an exponential increase in the threat of piracy and the loss of revenue for original content owners and producers. Now that electronic content can be copied much more easily, content owners have a greater need for content control. IP authentication and password access are not able to protect the content from being duplicated or shared, thus creating a need for greater rights management controls. At the same time, digital media distribution can bring a variety of new business opportunities for owners or generators of content who incorporate the right technologies to control their digital media distribution value chain [2]. Content, Creators and Rights Owners Packaging Service Providers, Distributors and Retailers Clients or Consumers Sponsors / Advertisers FIGURE 1.1. Distribution Value Chain The Distribution Value Chain shows the need for a safe and secure method for accesing, distributing and merchandaising digital content. It is important to notice the following aspects of each link of the chain [3]: 2
Content, Creators and Rights Owners: - Safeguards copyright integrity. - Assures revenue generation. - Expands business model alternatives. - Protects brand identity. Service Providers, Distributors and Retailers: - Maximizes business opportunities. - Protects revenue streams. - Minimizes risk of unauthorized distribution. - Expands potential customer base. Clients or Consumers: - Expands digital content choices. - Simplifies authorized playback. - Allows full-featured user experience. - Facilitates authorized portability between devices. 3
4
Chapter 2 Digital Rights Management: Technical description 2.1. ARCHITECTURE AND FRAMEWORK 2.1.1. SUMMARY The basic responsibility of a standards organization is to construct reference architecture. However, it is also necessary to create a mechanism that takes into account the innovation and the future growth of technological developments. This concept is embodied in the guiding principle adopted by several organizations with which the owner of the media contents (music and video) has been associated; a specification shall not preclude any technological solution that provides the requisite functionality demanded by the industry stakeholders. Components must be constructed in a modular manner and integrated into a flexible architecture so that the specification may survive. It is also necessary to develop a common language or structure that facilitates discussion of complex issues by parties with widely divergent points of view and vocabularies in order to implement any standardized scheme for the management of rights in digital environment. In this section we will study several architectures in order to define and give a framework to the DRM Solutions: Functional Architecture The Functional Architecture tries to modeled the total DRM framework in order to build digital rights-enable systems. It is a vision, in three areas, of how to manage the creation of content, the trade of the content and the use of the content. It stipulates, also, the roles and the behaviour of these three areas of Intellectual Property (IP). 5
Information Architecture The Information Architecture is a more flexible model to describe DRM framework. In order to do this description, this architecture take into account three main steps: to model the entities, to identify and describe them and to express the rights statements. This architecture tries to model the entities and their relationships. To do that, it defines the three core entities: Users, Content and Rights. Once the entities have been defined, it is necessary to express the rights that will be applied to the transactions between them (the Rights Expressions). The Information Architecture also evidences the need of a standard, like Open Digital Rights Language (ODRL), that models the Rights Expressions and their relationships because these Rights Expressions can became complex very quickly. Software Application Architecture The Software Application Architecture is a model from the technological point of view. It tries to explain different points: - The steps to get a correct, safe and security transaction: metataging, encryption, permissions... - The components of a typical DRM Software Architecture: content server, license server and client software. - The process of a DRM transaction: the differents steps between the server and the user since the user asks for the content until he receives it. These three different architectures give us a general vision, from different points of view (Intellectual Property (IP), entities and technological) of the DRM framework. Reference [4] has been one of the most important sources of information for this section. 2.1.2. FUNCTIONAL ARCHITECTURE The total DRM framework adapted to building digital rights-enabled systems can be modeled in three areas: Intellectual Property (IP) Asset Creation and Capture: How to manage the creation of content so it can be easily exchange. This includes asserting rights when content is first created (or reused and extended with appropiate rights to do so) by various content creators/providers. 6
IP Asset Management: How to manage and enable the trade of content. This includes accepting content from creators into an asset management system (we will see in section 2.2.2.: Digital Asset Management). The trading systems need to manage the descriptive metadata and rights metadata (e.g. parties, usages, payments, etc.). IP Asset Usage: How to manage the usage of content once it has been traded. This includes supporting contraints over traded content in specific desktop systems/software. The Functional Architecture provides a framework for the modules to implement DRM functionality (Figure 2.1.). So that, the Functional Architecture stipulates the roles and behaviour of a number of cooperating and interoperating modules under the three areas of Intellectual Property (IP): Asset Creation, Management and Usage. DRM Architecture IP Asset Creation Capture IP Asset Management IP Asset Usage Rights Validation Rights Creation Repository Trading Permission Management Tracking Managementt Rights Workflow Metadata Content Payments Fulfilment Parties Rights Works Licenses Packaging FIGURE 2.1. DRM Functional Architecture The IP Asset Creation and Capture module supports: Rights Validation: this is a part to ensure that content being created from existing content (e.g. a copy) includes the rights to do so. Rights Creation: to allow rights to be assigned to new content, such as specifying the rights owners and allowable usage permissions. Rights Workflow: this part is to allow that the content can be processed through a series of workflow steps for review and/or approval of rights (and content). 7
The IP Asset Management module supports: Repository functions: to allow the access/retrieval of the content in potentially distributed databases and the access/retrieval of metadata. The metadata covers Parties, Rights and descriptions of the Works. (See the Information Architecture section for more details). Trading functions: to enable the assignment of licenses to parties who have traded agreements for rights over content, including the payments from licenses to rights holders. In some cases, the content may need to go through fulfillment operations to satisfy the license agreement. For example, the content may be encrypted/protected or packaged for a particular type of desktop usage environment. The IP Asset Ussage module supports: Permissions Management: this is a part to enable the use associated with the content in accordance with the rights. For example, if the user only has the right to view the document, then printing will not be allowed. Tracking Management: it function is to enable the monitoring of the usage of content where such tracking is part of the agreed to license conditions (e.g., the user has a license to play a video ten times). This module may also need to interoperate with the trading system to track usage or to record transactions if there is payment due for each usage. These three modules and their relationships provide the core functionality for DRM systems. The modules have been described only at a high level, and they would also need to operate within other, existing e-business modules and Digital Asset Management modules (that we will study in 2.2.2. section: Digital Asset Management). Additionally, the modules would support other principles, requirements and characteristics, like interoperability, persistence, granularity, etc., that we will describe in next sections. The Functional Architecture is only one of the models that exist in order to describe the DRM framework. The fast advance of technological development causes that Rights Management can become complex. For this reason, DRM systems must support the most flexible model possible to provide these complex and layered relationships. The Information Architecture provides this [4]. 2.1.3. INFORMATION ARCHITECTURE The Information Architecture is another model to describe DRM framework, but more flexible. The development of this model consists in three main issues: Modeling the entities Identifying and describing the entities Expressing the rights statements They will be describe in the next sections. 8
2.1.3.1. MODELING THE ENTITIES It is important to adopt a clear and extensible model for the DRM entities and their relationship with other entities. There are currently four major active communities of rights-holders directly confronting these questions: based in the book and electronic publishing sector works the DOI community; the IFPI community of record companies; the ISAN community for producers, users, and rights owners of audiovisuals; and the CISAC community of collecting societies for composers and publishers of music, but also extending into other areas of authors' rights, including literary, visual, and plastic arts [5]. DOI (Digital Object Identifier) is a term that embraces a set of related initiatives centred on a persistent digital identifier (the DOI), a technology (Handle by the Corporation for National Research Initiatives,CNRI), and an organisation (the International DOI Foundation). Metadata definition has become a major issue for the DOI. MUSE is an EC-funded initiative of the record industry scheduled to announce (around October 1998) a secure means of encoding and protecting identifiers within digital audio. It is linked to the ISRC (International Standard Recording Code), and the project includes the specification of ISRC-related metadata. ISAN (International Standard Audiovisual Number) is backed by the film industry and collecting societies and is currently in draft in ISO TC46 sc9. It will be the backbone of several industry databases and related metadata sets. The CIS (Common Information System) plan is a copyright society-led international standardisation programme based on the integration of identifiers and related metadata to support efficient licensing and royalty distribution. Existing work in this area includes the <indecs> (Interoperability of Data in E- Commerce Systems) project [6]. The basic principle of the <indecs> model is to clearly separate and identify the three core entities: Users, Content and Rights, as shown in Figure 2.2. We will study this in section 2.4: The <indecs> project. Another view of <indecs> is the Commerce one. The cycle of making and using can go round and round indefinitely, although ultimately there will be end users who simply perceive or enjoy a creation with one or more of their senses. In the framework this gives rise to three basic types of commerce entity: Parties, Creations and Transactions. In the core entities model we can identify, as we said before, three parts [4]: Users entity: It can be any type of user, from a rights holder to an end-consumer, an agent undertaking an activity or task in a creative or commercial event. Content entity: that is any type of content at any level of aggregation, the output of creative activity. Rights entity: is an expression of the permissions, constraints, and obligations between the Parties and the Creations, an event determining or recording the use of possible use of an entity. 9
This model provides the greatest flexibility when assigning rights to any combination or layering of Users and Content. The Core Entities Model also allows Creations from being used in new and evolving business models. USERS Make Used by CONTENT do about RIGHTS FIGURE 2.2. Core Entities Model We could analyse the relationships, the rights and the descriptive metadata about the three entities. This metadata needs to include a mechanism to relate the entities to each other. The need for integration of metadata and rights management could be support for three propositions that set out a possible framework for an integrated approach. It based on models developed in the CIS plan and the DOI Rights Metadata group, and work on the ISRC, ISAN and ISWC standards and proposals [5]. The three propositions are: 1. DOI metadata must support all types of creation. 2. The secure transaction of requests and offers data depends on maintaining an integrated structure for documenting rights ownership agreements. 3. All elements of descriptive metadata (except titles) may also be elements of agreements. The main consequences of these propositions are: 1. A general and standard vocabulary is essential. 2. Non-confidential terms of rights ownership agreements must be generally accessible in a standard form. By this way, the network must be able to automatically determine the current owner of any right in any creation for any territory. 3. All descriptive metadata values (except titles) must be stored as unique, coded values. If we take into account these propositions, the implications on the behaviour and the future inter-dependency of the rights owner and content communities (audiovisual, visual, text ) are considerable. The CIS plan uses the generic term creation to denote a product of human imagination and/or endeavour by one or more Parties in which Rights may exist [5]. The term has the advantage that it does not carry much baggage. It is free of the connotations or legal matters of the narrower term work and it has not been employed in any specific sector until now. It is now employed as a basic term in the vocabularies of CIS, DOI and in the IMPRIMATUR business model. 10
Creations appear to come in four main structural types [5]: Structural type Medium (material) Examples Means of identification Package Physical (atoms, a single exemplar instantiation of an object) Book, CD, video, photograph, painting Printed text or barcodes (e.g., UPC/EAN, ISBN, ISSN, ISMN) Object Digital (bits, the digital embodiment of a performance of a work) Text, picture, audio, av file Digitally encoded (e.g., ISRC, ISAN, DOI ) Performance Spatio-temporal (actions, the intellectual or artistic realization of a work) Live performance of work, broadcast of recording In metadata only Work Abstract (concepts, ideas, a distinct intellectual or artistic creation) Musical composition, literary work In metadata only (e.g., ISWC, ISAN) TABLE 2.1. Creations: Structural Types Each structural type of creation may be manifested in any other. The same principles apply in audiovisual, visual, text and other primary types. The generic structural relationships are modelled in Figure 2.3. Physical Package Spatio- Temporal Performance Object Digital Relationships Work Abstract FIGURE 2.3. Creation Structural Types: Descriptive Data We could also say that creations can be said to be nested within each other: this also applies to creation of the same type (such as acts in a play or movements in a symphony). The phenomenon of nesting is the norm for most works, not the exception. When one creation is traded, a complex network of them may in fact be traded. A single multimedia creation may nest hundreds of audiovisual works, graphics, texts, audio recordings and all their underlying abstract compositions and works: often thousands of distinct creations with rights owners attendance. 11
E-commerce creates the ability for each component creation to be individually discovered, identified, offered, acquired and for the resulting transaction to be accounted to source, although it does not mean anything new about the relationships in themselves. This scalability has different implications. The creations can be used, adapted or combined in several ways with electronic tools in an environment which will be accessible in time to billions of users. For that reason, the issues of secure protection and billing are very important. However, under the analysis being carried out within the communities identified above and by those who are developing technology and languages for rights-based e-commerce, it is becoming clear that functional metadata is also a critical component. It is metadata (including identifiers) which defines a creation and its relationship to other creations and to the parties who created and variously own it; without a coherent metadata infrastructure e-commerce cannot properly flow. Securing the metadata network is every bit as important as securing the content, and there is little doubt which poses the greater problem [5]. 2.1.3.2. IDENTIFYING AND DESCRIBING THE ENTITIES Generically, we call Parties to people and companies, as shown in Figure 2.4. (a simpler form of the CIS term Interested Party). Names as identifiers are helpful for discovery but inadequate for secure identification and dangerous as a basis for automated e-commerce transactions because they are not unique, for this reason the parties require unique structured identifiers. Parties Author Corporate Agent Publisher FIGURE 2.4. Parties model Because parties may make creations and own rights of any kind, party metadata must be adaptable to all creation types [5]. We need to identify and describe all entities. Identification should be done via open and standard mechanisms for each entity in the model. Both the entities and the metadata records about the entities must be identifiable. Open standards such as Uniform Resource Identifiers (URI) and Digital Object Identifiers (DOI) (that we will study in section 3.2.2) and the emerging ISO International Standard Textual Work Code (ISTC) are typical schemes useful for Rights identification. 12
For describe each different type of Content, it should be used the most appropriate metadata standard (for example, the EDItEUR ONIX standard (ONIX) for books (physical and electronic) and the IMS Learning Resource Meta-data Information Model (IMS) for educational learning objects). Such metadata standards do not themselves try to include metadata elements in order to address rights management information, for this reason, it could be a problem how to describe such rights expressions. For example, the ONIX standard has elements for a number of rights holders (e.g., Authors and Publishers) and Territories for rights and single Price information. (The latter poses a problem in setting multiple prices depending on what rights are traded). In such cases, following the <indecs> model should take precedence. To describe Users, vcard (VCARD) is the most well-known metadata standard for describing people and (to some extent) organizations. Rights model has to explain and fix the roles that Parties have with respect to Content [4]. At the present time, ownership and exploitation of rights in different creation-types is the norm. The majority of the enterprises in the different sectors do e-business with text, pictures, graphics, photographs, audiovisuals and sound recordings and, in general terms, there are no essential operational differences between them. So, the metadata framework has to cover all their requirements. It should also be considered that, in operational terms, there may be little or no difference between the digital transactions of different e-business enterprises. 2.1.3.3. EXPRESSING RIGHTS STATEMENTS People that make Creations have to assign Rights in them to other people or companies through Agreements. CIS defines a Right as the authority originating in law or by international convention for a Party to do or to authorise another Party to do a defined act to a Creation [5]. An agreement is a written or unwritten accord between Parties which determines Rights or entitlements in relation to Creations for a given Place and Time [5]. Figure 2.5. shows these relationships, which models the fundamental entity relationships that form an integrated model. Agreements cover everything from a copyright act at one extreme to the terms of a single download transaction at the other. 13
Component Party Creation Component Relationship Relationship PARTY Contributor CREATION Party Schedule AGREEMENT Component Agreement Term Term Term PLACE RIGHT TIME FIGURE 2.5. Primary Entity Relationships: Integrated Data Model A grant (or refusal) of rights can describe every transaction that involves creations, even where the rights are in the public domain. These transactions can be described in the same terms for physical packages, digital objects or abstract works, although the grant of rights have to go with different consequences for different structures. The Rights entity allows transactions to be made about the allowable permissions, constraints, obligations, and any other rights-related information about Parties and Creations. By this way, the Rights entity is critical because it represents the expressiveness of the language that will be used to inform the rights metadata. It is necessary to model rights expression and the relationships between them, because rights expressions can become complex quickly. Open Digital Rights Language (ODRL) (that we will study in 3.2.1. section) is a very good example of that [5]. As shown in Figure 2.6., Rights expressions should consist of: Permissions/usages Constraints Obligations Rights Holders Rewards What you are allowed to do Restrictions on the permissions What you have to do/provide/accept Who is entitled to what What you obtain TABLE 2.2. Rights Expressions 14
For example, a Rights expression may say that a particular video can by played (i.e., a usage permission) for a maximum of 10 times (i.e., a count constraint) in any semester (i.e., a time constraint) for a $10 fee (i.e., an obligation to pay). Each time the video is played, John, Mary, and Sue (the rights holders) receive a percentage of the fee. Usually, if a right is not explicit in an expression, it means that the right has not been granted. This is a critical assumption made by Rights languages and should be made clear to all Users. For an example of a rights language, see the Open Digital Rights Language (ODRL). ODRL lists the many potential terms for permissions, constraints, and obligations as well as the rights holder agreements. As such terms may vary across sectors, rights languages should be modeled to allow the terms to be managed via a Data Dictionary and expressed via the language [4]. Percentage Fixed Rewards Rights Holders Count Quantity Pay Tracking Obligations RIGHTS Constraints Territory Devices Loyalty Points Usages Time Play Lend Print Reuse FIGURE 2.6. Rights Expression Model 2.1.4. SOFTWARE APPLICATION ARCHITECTURE From the technological point of view, we have to follow different steps to do a correct and safe transaction: First step: once the assets have been created it is necessary to provide a flexible DRM technology strategy capable of meta-tag the assets and store them in databases and media asset management technologies. Second step: the information, after the assets are metatagged, is encrypted to ensure the security of the content. Third step: once we have obtained the permissions and authorizations that we need to, the content can be transmitted (a decrypted key unlocks protected content) and displayed in a secure and trusted environment via a client technology. In order to determine the rights and policies for use the assets, as we have seen previosly, a set of rules have created in most of the commonly used DRM software applications for text, audio, video and software. The use of DRM software applications during the creation phase of digital content works towards creating a trusted environment where both the sender and the 15
consumer can be assured that the content they receive was indeed sent by the appropriate party and in security conditions and that the consumer is authorized to receive the content. ERP Content Server Commerce Copyrights Permissions Content Files Busienss Rules Card Processing Tax Calculation Finance Meta Data, Assets Rights Packager Transactions Marketing R & D Digital Asset Management System Content Workflow System (CMS) SSL AVS License Decrypter Rendering Client License Manager Content Library Sales Management DRM License License Server Order Manager License IDs Settlement Territory Management DRM Handler Rights Manager View/ Play/Print Commerce Manager Account Manager License Creator FIGURE 2.7. Generic DRM Software Application Architecture DRM architecture typically consists of the following components: Content Server: consisting of four blocks: 1. A content repository containing a metadata management environment to uniquely identify the digital assets. Some of the more efficient DRM software applications can integrate with asset management systems. 2. Product information, consisting of rights and product metadata. 3. A packager that encrypts the content with the appropriate mechanisms to unlock the content upon delivery to an end user. 4. A delivery mechanism that will be as DRM format independent as possible. License Server: consisting of three components: 1. An encrytion key repository. 2. A user identity database that collects the content. 3. A DRM license generator that binds the content and the encrytion key to the end user s device and registers the user with the appropriate parties that make up the digital dstribution value chain. Client Software: A piece of software that resides locally on an end user s device that displays the encrypted content, communicating the appropriate rights and permissions to the end user and back to the license server. The number of communications back to the license server is determined by the contents rules at the time of packaging. 16
DRM processes typically take place in the following order (see Figure 2.8): 1. The user obtains the content packages using various digital delivery services. 2. The user requests the content usage operation (e.g., view, play) within the client application. 3. Once the user abides by the appropiate registration (e.g., name, address, e-mail), payment and clearing methodologies (e.g., credit card, purchase order, taxes) for operation, the DRM license handler collects the user and content asset information and produces a license to decrypt the asset on the end user s device. Depending upon the specific type of DRM software application used by the content creator, the license delivery process may happen simultaneously during the financial clearing part of the content delivery [2]. SERVER USER Content Package Content Usage Request Operation (registration, payment, clearing) requests Validation Data Content FIGURE 2.8. DRM processes between Server and User 17
2.2. REQUIREMENTS 2.2.1. SUMMARY In the previous section we have studied several architectures in order to define and give a framework to the DRM Solutions. Once we have the framework, we need to know the requirements to develop an effective DRM solution. For this purpose, in this section, we are going to study the following points: Digital Asset Management (DAM) In order to complete a DRM solution it is necessary a good Digital Asset Management (DAM) System. In fact, DAM is a basis of effective Rights Management. This kind of systems give to the enterprises a competitive advantage: to stablish an asset repository that enables the association of essential rights and permissions information with specific assets. Technically, a DAM System stores, indexes, categorizes, secures, searches, transforms, assembles and exports intellectual property. Trusted System Once the DAM System has been chosen, it is necessary to guarantee that the transactions will be reliable by means of the identification of system participants, access restrictions, protection of digital content, etc. Trusted systems allow to solve these problems that are associated with digital content management. Expression Language In order to standarize the expressions that are used in the information about intellectual property rights in digital transactions a general vocabulary is needed. The objective is to get automated rights transacions in an universal language and, to do that, it is necessary a machine readable that permits to realize the conversion of original rights granted into usage permissions for digital transactions in an automatical and unique way. Protection Up to now, we have a system that manages the intellectual property (DAM System), that guarantees secure digital transactions and a common language that expresses the information about intellectual property rights. Now, we need to protect and prepare the digital content and the transaction environment in order to avoid piracy and illegal exploitations. To do that, different technologies are used and we are going to study the following ones: - Conditional Accesss Systems: in order to give access to the digital content only to suscribers. - DRM Systems: in wich the client obtains the content in protected form and with a license that specifies the uses for it. - Software: to avoid that the digital content can work on an unlicensed machine. 18
- Protection Technologies: methods for protection for the digital content to prevent piracy, to ensure integrity, to enforce the user the terms of license agreement, etc. We will study Cryptography (Conventional Cryptography, Public Key Cryptography, Digital Signature and Keys), Software Security Dongles, Watermarking (Digital Watermarking for Video and Digital Watermarking for Audio) and Fingerprinting. Trading Architectures To conclude, trading architecture helps enterprises to provide the users an environment to share data, applications and processes by means of internet-based technologies. We will study the principal components, the requirements and general architectures of a trading system. 2.2.2. DIGITAL ASSET MANAGEMENT Any company that wishes to obtain a competitive advantage in business must to have the content rights on they own and, thanks to that, this company will obtain an efficience inventory of their assets. Precisely because of that, it is necessary a basis for effective Rights Management: Digital Asset Management (DAM) Solutions. DAM software will stablish an asset repository that enables the association of essential rights and permissions information with specific assets at the very beginning of the DRM value chain. Due to the modular design of a DAM system (the best DAM solutions also have the capability to integrate with other DRM funcional applications), documented APIs and strong relationships with different partners, it is possible to ensure that consumers can use DAM to provide extended DRM functionality that grows with their business. In order to complete a Digital Rights Management Solution, one of the most important steps is to choose a good Digital Asset Management system. By this way and thanks to DAM solutions, a lot of companies are building a strong foundation for a digital business strategy and, for this reason, are positioning themselves to take the competitive advantage [8]. Technically, Digital Asset Management stores, indexes, categorizes, secures, searches, transforms, assembles and exports content that has monetary or cultural value. Digital assets often include rich media such as video, audio and graphics, but this is not a requirement, the main characteristic of a digital asset is that it is an asset. On the other hand, the fact that an asset is represented digitally presents numerous opportunities for revenue generation and operational efficiency; for this reason, a digital asset management platform gives preference to functionality and is quite different from other classes of software. There are three essential elements that distinguish Enterprise Digital Asset Management solutions from other content management solutions: 1. All the system functions is the asset (security, search results, transactions, rights ), defined as specific combinations of content and data that have financial (monetary or cultural) value. 19
2. Each functional component of a Digital Asset Management solution including, but not limited to, store, indexing, cataloguing, navigation, transformation and export must offer thorough support for all types of media including streaming and still formats and for all traditional and e-delivery channels. 3. The architecture needs to be a basis component and an important value for the company, able to assure fulfillint the operations, scalable performance and distributed access throughout the extended organization. In DAM systems it is very important the definition of an asset. There is general agreement that a digital asset is the asset's content plus metadata (or data about the content, as we have said before). Metadata can include information about format type, rights and permissions, usage history, etc. This kind of information is typically well suited to be stored in fields, e.g. as simple data elements [9]. When we have another type of related information, it is better to model it as relationships between assets. For this reason, it exits a complementary technology to DAM systems: link engines. This technology supplements classic metadata fields and can capture the relationships between assets and any other type of relationship that can occur between complex and compound digital assets. Another widely used approach for providing context (and therefore additional value) to digital assets is the technique of categorization. Organizing digital assets into hierarchies (or webs) or related categories serves as a powerful organizing principle, simplifies navigation and provides a great advantage in relation to other search techniques. The following figure illustrates the logical model for a Digital Asset: the definition and management of content, metadata (information about the content), and every other related information and behaviour is organized around the asset [9]. Vocabulary Sets Links ASSET Object Location Fielded Model (Metadata) Rights & Permissions FIGURE 2.9. Logical Model of a Digital Asset 20
This logical model of a Digital Asset is an extended metadata approach, that can be used to track physical assets as well, that adds to the three mainly facets of fielded metadata, links and categories (vocabulary), additional information about rights and permissions, aggregations of assets (membership in sets) and mapping to the physical location of a digital asset. Nowadays, every enterprise has the need to support all types of media content. From the technical point of view, it becomes clear that the way one stores, indexes, previews, navigates, transforms, secures and transports digital assets is highly dependent on the type of media that the digital assets are composed of. The behaviours that correspond to DAM functionality are radically different and demand distinct technological solutions. When an Enterprise demands a DAM solution to another will not only looks for a system that supports a broad array of media types, the Enterprise looks for a solution based upon a modular architecture that will permit incremental extensions to accommodate new media types and increasingly sophisticated behaviours. Use cases, logical workflows, functional requirements and appropiate code are completely distinct as one considers different media types. In conclusion, Digital Asset Management has clearly emerged as a critical component of IT infrastructure and has left behind its early niche as specialized software for effective Rights Management. The Internet revolution and the convergence of digital media has catapulted Digital Asset Management across the enterprise and into e-business industries [9]. 2.2.3. TRUSTED SYSTEMS The Trusted systems notion was based on concepts of Trust Management, that has appeared as a new philosophy of encryption, analysis and trusted solutions management in computer systems. With the appearance of World Wide Web this concept was advanced and extended for using in terms of opened decentralizing systems that consist of the multiple administrative domens. Before to trust whomever from system participants (trustee) to execute some action on some object, there are a basic principles of trust management to follow: to be exactly aware of privilege of this participant (trustee), to entrust himself in the event of the external request and to be careful before and after performing this operations. In the process of creation trusted systems these principles are realized by performing the following requirements: Identification of system participants; Connecting of access restrictions with each system element; Assuming the authorized solutions in accordance with some rules. For this purpose both software and single-purpose hardware devices can be used. In order to realize these requirements, it is necessary to ensure a flexibility level and protection of trusted systems in terms of open network environment. Due to this, in the second half of 90s the researches on using the trusted systems for controlled spreading of digital 21
intellectual property were started. As a result of these researches up to year 2000 a point of view was formed, in accordance with which digital rights management systems are to be considered and created as trusted systems. Trusted systems allow to solve some key problems associated with digital content management: trusted systems allow publishers to put a set of rights in correspondence of specific digital work, according to which user shall use this work; trusted systems enforce user to meet the conditions and requirements of license agreement between publisher and user of digital content; trusted systems ensure integrity and protection of digital documents during the transactions across open networks; trusted systems can get information from other trusted systems and define inauthentic or wrong given data; trusted systems ensure confidentiality of user information. As we are studying, concept of rights is a key in digital intellectual property management systems. It includes both copyrights associated with digital work, and rights of publishers, as well as usage rights that can be obtained by user. As shown before, there are several types of rights, for each type of right can be determined a charge, which user of content should pay for its realization. Besides, for each type of right are to be determined term of access that define who from users can realize this right [10]. To ensure a relationship between digital documents and rights, different companies and consortiums have designed and developed several special interpreted description language of the digital rights, as we will see in Expression Language (section 2.2.4.). When a buyer acquire a digital work, through a right management system, enters into a digital contract with the publisher, assuming the obligations to execute the rights associated with it.that contract also defines ways of possible using of digital product. Another characteristic of trusted systems is the presence of mechanisms that enfore the buyer to meet the terms of digital contract. Once the server and the user are connected, with the necessary permissions on the part of the user, the transaction can carry out by two ways: by development of solutions based on software only by means of shared use of special hardware devices and software. Nowadays companies are using the first way, developing technological solutions for digital rights management and sale of electronic content. However the use of only software solutions does not ensure required protection of digital work and protection of rights of owners. As a result, the number of hacker attacks on protected electronic publications has increased. The second way can be realized by using the trusted peripherals for rendering, print or copying of the digital documents. The trusted systems work, as we have shown, in digital content management and the conexion with it rights. This work allows to organize a protected, secure and safe transfer of digital work between the author and publisher to the seller and buyer. 22