Digitale rechten: onderzoek naar state-of-the-art technologieën en ontwikkeling van een MPEG-21 REL parser

Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout

Digitale rechten: onderzoek naar state-of-the-art technologie¨ en en ontwikkeling van een MPEG-21 REL parser door Bert Christiaens

Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. R. De Sutter

Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica

Academiejaar 2003-2004

Dankwoord Ik wens iedereen te bedanken die mij geholpen heeft. De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.

i

Digitale rechten: onderzoek naar state-of-the-art technologie¨ en en ontwikkeling van een MPEG-21 REL parser door Bert Christiaens Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar 2003-2004 Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. R. De Sutter

Samenvatting Bescherming van intellectuele eigendomsrechten die rusten op digitale objecten is reeds enige tijd een “hot topic”. Verschillende “Digital Rights Management” (DRM) systemen werden reeds ontwikkeld, met wisselend succes. Het doel van “DRM” is het aanbieden van een framework zodat de producent zijn data beter kan beschermen tegen allerlei vormen van computerpiraterij. “DRM” werd ook in het leven geroepen om het intellectueel eigendomsrecht op digitale objecten te verzekeren, door de producent de mogelijkheid te bieden rechten te defini¨eren op het gebruik van zijn data. Deze thesis omvat een literatuurstudie omntrent DRM (hoofdstukken 1 t.e.m. 4) en een praktisch gedeelte (hoofdstukken 5 en 6). Hoofdstuk 1 kan gezien worden als een inleidend hoofdstuk. Er wordt o.a. uitgelegd wat “DRM” betekent, hoe het concept is ontstaan, wat de voor- en nadelen zijn van “DRM”, hoe “DRM” gerelateerd is tot de wet... In hoofdstuk 2 worden een aantal “Rights Expression Languages” (RELs) onderzocht. Na afweging van positieve en negatieve kenmerken wordt dan een algemene, hypothetische REL omschreven, die kan gezien worden als “de ideale REL”. Hoofdstuk 3 onderzoekt welke DRM architecturen er in de praktijk voorkomen waarna een algemene theoretische architectuur wordt afgeleid. Hoofdstuk 4 gaat na welke soorten beveiligingstechnieken er worden gebruikt binnen een DRM architectuur, zowel op gebied van kopiepreventie als kopiedetectie. Tevens worden een aantal praktijkvoorbeelden belicht.

ii

De laatste twee hoofdstukken vormen het praktisch gedeelte van dit afstudeerwerk. In hoofdstuk 5 ga ik na wat de huidige ontwikkelingen zijn binnen MPEG-21 door het onderzoeken van huidige referentiesoftware. Het laatste hoofdstuk geeft een algemene en technische beschrijving van de “MPEG-21 REL parser” die ik heb geschreven en de koppeling van deze parser aan bestaande referentiesoftware. In een laatste gedeelte (algemeen besluit) wordt een totaalbeeld van de thesis geschetst door het samenrapen van de conclusies en resultaten uit alle hoofdstukken. Trefwoorden: DRM, MPEG-21, digitale rechten, DRM architectuur, MPEG-21 REL parser, REL

iii

Inhoudsopgave I

Theoretisch gedeelte

1

1 DRM algemeen 1.1

1.2

2

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.1.1

Wat is DRM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.1.2

Oorsprong en historische achtergrond van DRM [14] . . . . . . . . .

4

1.1.3

Waarom is DRM belangrijk? . . . . . . . . . . . . . . . . . . . . . .

5

1.1.4

Waarvoor kan DRM gebruikt worden? . . . . . . . . . . . . . . . .

6

1.1.5

DRM en standaardisatie . . . . . . . . . . . . . . . . . . . . . . . .

6

Voor- en nadelen DRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.2.1

Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.2.2

Nadelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.2.3

Economische gevolgen . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3

DRM en de wet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Rights Expression Languages

14

2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2

Studie naar bestaande RELs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2

ODRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3

XrML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.4

MPEG-21 REL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.5

LicenseScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.6

Andere RELs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iv

2.3

2.4

Vergelijking RELs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.1

Vergelijking XML-gebaseerde RELs onderling [49] . . . . . . . . . . 27

2.3.2

Vergelijking XML-gebaseerde RELs en logisch gebaseerde REL LicenseScript [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Voorstelling van een hypothetische REL . . . . . . . . . . . . . . . . . . . 28 2.4.1

Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.2

Mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5

REL en copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.6

Rights Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7

Voorbeelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.8

2.7.1

XML gebaseerde RELs . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7.2

Logische REL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 DRM architecturen

36

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2

Onderzoek naar architecturen in de praktijk . . . . . . . . . . . . . . . . . 36 3.2.1

Windows Media Player . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2

Windows RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.3

Real Helix DRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.4

Quicktime iTunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3

Algemene architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4

Verdere beschrijving van een DRM architectuur . . . . . . . . . . . . . . . 46

3.5

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 DRM en beveiliging

50

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2

Kopiepreventie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3

4.2.1

Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.2

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.3

Combinatie hard- en software . . . . . . . . . . . . . . . . . . . . . 54

Kopiedetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.3.1

Watermerken [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 v

4.4

4.5

4.6

II

Beveiliging in de praktijk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4.1

Adobe Merchant en Adobe Web Pay [2]

. . . . . . . . . . . . . . . 55

4.4.2

Microsoft NGSCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Beveiligingsinbraken [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.5.1

Dimitry Sklyarov en Adobe eBook kopieprotectie . . . . . . . . . . 60

4.5.2

Ed Felten: een academische inbraak in DRM Systemen . . . . . . . 60

4.5.3

Stephen King en “Riding the Bullet” . . . . . . . . . . . . . . . . . 60

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Praktisch gedeelte

62

5 Onderzoek naar MPEG-21 referentiesoftware

63

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2

MPEG-21 REL referentiesoftware . . . . . . . . . . . . . . . . . . . . . . . 64

5.3

5.2.1

License Schema Checker . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.2

License Validation Rules Checker . . . . . . . . . . . . . . . . . . . 65

5.2.3

License Creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.4

License Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

MPEG RDD referentiesoftware . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3.1

RDD Browser Interface . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.2

RDD Database Query . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4

Referentiesoftware als combinatie van MPEG-21 delen . . . . . . . . . . . . 71

5.5

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Ontwikkeling van een MPEG-21 REL parser en toepassing

73

6.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2

MPEG-21 REL Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.2.1

Algemene beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2.2

Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.3

Technische beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2.4

Hi¨erarchie Core schema . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2.5

Ontwerpsbeslissingen . . . . . . . . . . . . . . . . . . . . . . . . . . 80

vi

6.3

Toepassing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.4

“REL license interpretation with DID” . . . . . . . . . . . . . . . . . . . . 83

III

6.4.1

Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.4.2

Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.4.3

Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Algemeen besluit

88

A

93

B

98

C

108

vii

Lijst van figuren 1.1

Aantal DRM gerelateerde firma’s tussen 1999 en 2001 . . . . . . . . . . . . 10

2.1

ODRL Foundation Model (Basis van ODRL) [24] . . . . . . . . . . . . . . 16

2.2

XrML Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3

XrML basic data construct . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4

XrML structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5

LicenseScript: transformatie van licenties . . . . . . . . . . . . . . . . . . . 24

3.1

Windows Media Player: DRM architectuur . . . . . . . . . . . . . . . . . . 37

3.2

Windows Rights Managing Services: architectuur . . . . . . . . . . . . . . 40

3.3

Algemene DRM architectuur (Bron: B. Rosenblatt. DRM: Business and Technology[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4

Algemene DRM architectuur met copyright component (Bron: B. Rosenblatt. DRM: Business and Technology[14] . . . . . . . . . . . . . . . . . . 45

5.1

MPEG-21 REL: License schema checker . . . . . . . . . . . . . . . . . . . 64

5.2

MPEG-21 REL: License validation rules checker . . . . . . . . . . . . . . . 65

5.3

MPEG-21 REL: License creator . . . . . . . . . . . . . . . . . . . . . . . . 67

5.4

MPEG-21 REL: License interpreter . . . . . . . . . . . . . . . . . . . . . . 68

6.1

Omzetting REL-document naar objectstructuur van REL elementen . . . . 74

6.2

Gebruik van de MPEG-21 Terminal om een REL-document te parsen . . . 76

6.3

Core schema: voorstelling elementen License en Issuer . . . . . . . . . . . . 79

6.4

MPEG-21 REL: REL license interpretation with DID . . . . . . . . . . . . 84

6.5

Snapshot REL license interpretation with DID . . . . . . . . . . . . . . . . 87

1

LicenseScript: voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

2

ODRL: voorbeeld van een offer . . . . . . . . . . . . . . . . . . . . . . . . 109 viii

3

MPEG-21 REL / XrML: voorbeeld van een “Use License” . . . . . . . . . 110

ix

Lijst van tabellen 2.1

Vergelijking RELs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

x

28

Deel I Theoretisch gedeelte

1

Hoofdstuk 1 DRM algemeen 1.1

Inleiding

Tegenwoordig is het Internet een medium dat niet meer weg te denken is uit ons leven. Ze omvat naast bibliotheken vol informatie ook tal van functionaliteiten, die de mens uit de 21ste eeuw helpen in al zijn behoeften. Online het nieuws bekijken, chatten, e-commerce, ... Noem maar op. Deze functionaliteiten ondervinden vaak hinder van minder rechtmatig gebruik en piraterij. Het grootste probleem is dat het Internet meer en meer gebruikt wordt voor “gedigitaliseerde” versies van bepaalde zaken. Denken we maar aan e-books, MP3 en digitale video. Door deze dematerialisatie is er een groter gevaar dat laatst opgenoemde zaken gemakkelijk gekopieerd worden. Ze bestaan uiteindelijk enkel maar uit bits en het is dus mogelijk om een perfecte kopie te maken, daar waar dat niet mogelijk is bij de materi¨ele versies (de perfecte kopie van een materieel object bestaat niet). Daarnaast is digitale data ook eenvoudiger te veranderen en te manipuleren daar waar dit bij materi¨ele versies moeilijk (onmogelijk) is. Als men dus dergelijke digitale data op een veilige manier over het Internet wil verspreiden, heeft men nood aan een “controlerend en beschermend” systeem. DRM werd vooral ontwikkeld voor de industrie die meer en meer gebruik maakt van Internet voor z’n economische doeleinden. DRM biedt tal van voordelen: niet enkel kan men de eigen data beter beschermen tegen illegale praktijken, ook kan men meer mogelijkheden (nieuwe businessmodellen) voorzien naar de consument toe. Door de geavanceerde mogelijkheden

2

van DRM kan men het intellectueel eigendomsrecht beter afdwingen op digitale objecten. DRM vangt ook de torenhoge verliezen op die bedrijven lijden door computerpiratij en lekken van belangrijke informatie. Wat als een auteur zijn boeken online wil zetten? Kan hij er zeker van zijn dat ze op de snelweg van het Internet niet illegaal worden geraadpleegd? Hoe kan een muzikant bepalen welke van zijn liedjes al of niet mogen beluisterd worden door een muziekliefhebber? Hoe kan hij z’n auteursrechten afdwingen op z’n digitale realisaties? Om op deze vragen een gunstig antwoord te kunnen geven werd het algemeen concept “DRM” ingeleid.

1.1.1

Wat is DRM?

DRM of Digital Rights Management is moeilijk eenduidig te defini¨eren. De term ontstond in de late jaren ’90 door samenspraak van verkopers en industri¨ele analisten. Het is een abstract en ruim concept dat op verschillende manieren kan omschreven worden. In mijn literatuurstudie ben ik verschillende “beschrijvingen” tegengekomen [4]: 1. “Digital Rights Management (DRM): the management of rights to digital goods and content, including its confinement to authorised use and users and the management of any consequences of that use throughout the entire life cycle of the content.” 2. “The term DRM means the chain of hardware and software services and technologies governing the authorised use of digital content and management of any consequences of that use throughout the entire life cycle of the content.” 3. “DRM refers to the technologies and/or processes that are applied to digital content to describe and identify it and/or to define, apply and enforce usage rules in a secure manner.” 4. “DRM includes a range of functions to support the management of intellectual property for digital resources. These functions include description, identification, trading, protection, monitoring and tracking of digital content. DRM systems also support the expression of rights offers and agreements (e.g. licenses) for content and all the parties involved (including rights holders).” Uit deze definities heb ik volgende omschrijving gedestilleerd:

3

Digital Rights Management bestaat enerzijds uit beveiligingstechnieken (zowel op softals hardwareniveau) voor data en anderzijds uit mechanismen om data te identificeren, te beschrijven en te beschermen door het afdwingen van intellectuele eigendomsrechten. DRM streeft naar het ontwikkelen van een veilig systeem, waarin digitale objecten veilig en snel kunnen uitgewisseld worden tussen producent en consument. DRM onderhoudt dus het intellectueel eigendomsrecht en controleert de verspreiding van digitale data. Het moet opgemerkt worden dat DRM digital management of rights is en niet management of digital rights. DRM onderhoudt dus alle rechten, niet enkel rechten die toepasbaar zijn op digitale data (DRM kan bijvoorbeeld gebruikt worden als controlerend orgaan bij een databank van ziekenhuisfiches). DRM is ge¨evolueerd van een eerste generatie naar een tweede generatie van systemen. De eerste generatie DRM systemen was vrij beperkt. Ze beveiligden de data en enkel mensen die betaalden kregen toegang tot de data. De eerste generatie DRM had dus veel weg van een gewoon beveiligingssysteem. Door de immateri¨ele verandering bleek dat dit systeem niet meer krachtig genoeg was. Een tweede generatie DRM systemen werd dan ook veel geavanceerder en uitgebreider - naast het simpelweg beveiligen van data, had men ook oog voor volgende zaken: 1. Beschrijving van data. 2. Identificatie van data. 3. Defini¨eren van intellectuele eigendomsrechten over data (beheer van rechten). 4. Opvolgen van data (in het Engels wordt dit “tracking” genoemd). De DRM architecturen die ik onderzocht heb, bieden ondersteuning voor al deze opgenoemde kenmerken. Ik zal ze in hoofdstuk 3 verder bespreken.

1.1.2

Oorsprong en historische achtergrond van DRM [14]

Zoals aangehaald in de inleiding begon de ontwikkeling van DRM met de opkomst van het Internet. Maar ook daarvoor waren al kenmerken van de hedendaagse DRMtechnologie aanwezig, zei het dan in meer beperkte mate.1 Het Internet is verantwoordelijk 1

Deze kenmerken vindt men terug in de eerste grote mainframe-systemen van de jaren ’80, waar men het gebruik van bestanden door vele gebruikers wilde controleren en reguleren.

4

voor de grote toename in distributiemogelijkheden, daar waar dat voorheen veel beperkter was door het gebruik van diskettes en cd-rom. Het werd dan ook snel duidelijk dat er een systeem moest ontwikkeld worden die rekening hield met mogelijks toenemende piraterij. Toen het Internet in 1994 begon aan z’n commerci¨ele opgang besefte men ook dat het onderhouden van het intellectueel eigendomsrecht op digitale data zeer noodzakelijk was. Deze 2 hoofdaspecten (tegengaan van computerpiraterij en onderhouden van het intellectueel eigendomsrecht) droegen bij tot de geboorte van DRM. De eerste DRM systemen die werden ontwikkeld waren “infoMarket”[25] van IBM en een systeem ontwikkeld door EPR[31]2 . Hoewel deze systemen op zich niet erg succesvol waren droegen ze toch hun steentje bij tot de verdere ontwikkeling van DRM. Een belangrijk figuur in de wereld van DRM is Dr. Mark Stefik die met z’n publicatie “Letting Loose the Light: Igniting Commerce in Electronic Publication”, de algemeen technische basis legde voor DRM. Stefik was ook grondlegger van DPRL [11], een eerste rights expression language waarvan XrML een derivaat is. Momenteel blijft de ontwikkeling van DRM in een sterk stijgende fase; verschillende groeperingen pogen met hun vooropgestelde systemen de standaarden te leggen voor de toekomstige DRM-technologie.3

1.1.3

Waarom is DRM belangrijk?

Zoals reeds in de inleiding aangehaald is DRM belangrijk in de evolutie van materi¨ele naar immateri¨ele data. Ze moet zorgen voor een veilige verspreiding van gedigitaliseerde data en moet dienen als bijkomend controle-orgaan. Daarnaast is DRM ook belangrijk voor de industrie. Digital Rights Management moet de grote verliezen van bedrijven opvangen en zorgt er ook voor dat bedrijven nieuwe businessmodellen4 kunnen gebruiken, waardoor ze de consument beter kunnen benaderen en dus ook meer winsten kunnen boeken. DRM is ook zeer belangrijk in het kader van computerpiraterij. DRM tracht kopie¨en te detecteren en probeert het kopi¨eren ook te verhinderen door een aantal specifieke 2

EPR is nu beter bekend onder de naam Intertrust[31], ´e´en van de grootste namen in het huidig DRM landschap. Intertrust[31] heeft onlangs een samenwerkingscontract met Microsoft afgesloten, Microsoft krijgt de volledige toegang tot de DRM-technologie van Intertrust. 3 Recent nog werd MPEG REL door de ISO groepering erkend als standaard. 4 zie “voor- en nadelen DRM” voor enkele voorbeelden.

5

technieken aan te wenden. Het zou natuurlijk idealistisch zijn te denken dat DRM het piraterijprobleem voorgoed uit de wereld zou helpen. DRM probeert enkel het kopi¨eren moeilijker te maken door enerzijds technische middelen te hanteren en anderzijds ook door een vorm van standaardisatie door te voeren waardoor het kopi¨eren oninteressant wordt.

1.1.4

Waarvoor kan DRM gebruikt worden?

DRM kan gebruikt worden voor commerci¨ele doeleinden, zoals bijvoorbeeld een online boekenwinkel. Daarnaast kan het ook nog gebruikt worden voor niet-commerci¨ele doeleinden, hierbij denk ik bijvoorbeeld aan het beschermen van betrouwbare informatie (bijvoorbeeld bescherming van geheime documenten in het FBI, de vliegtuigindustrie, de financi¨ele wereld...), in dat geval spreekt men soms van “ERM” d.i. Enterprise Rights Management. Digital Rights Management kan ook gebruikt worden voor bescherming van persoonlijke data (bijvoorbeeld het Windows RMS systeem in Office 2003 [67]). Bij al deze gebruiken dient opgemerkt te worden dat DRM zich nog in een experimentele fase bevindt, en dat effici¨ente systemen voor bijvoorbeeld persoonlijk gebruik nog niet voorhanden zijn.

1.1.5

DRM en standaardisatie

Door de tijden heen is gebleken dat standaardisatie heel wat voordelen heeft. De eerste vorm van standaardisatie was het invoeren van gewichten. Dit werd gedaan om de eerlijkheid tussen de mensen te bevorderen. De Egyptenaren voerden de cubit in, een uniforme lengtemaat die gebruikt werd zodat gemakkelijk kon gecommuniceerd worden bij het bouwen van monumenten zoals de pyramides. Napoleon voerde dan weer het metrisch stelsel in, zodat er meer orde was bij z’n troepen en men tactischer ten strijde kon trekken. Ook heden ten dage wordt er op commercieel gebied standaardisatie doorgevoerd: het biedt een algemene infrastructuur die door iedereen interpreteerbaar is. Een voorbeeld van een moderne standaard is de Bolero standaard voor de scheepvaartindustrie. Voor de invoering van deze standaard waren er vele kosten i.v.m. beheren van ladingen en communicatie tussen schepen onderling. Doordat men in de scheepvaartindustrie nu de “Bolero papierloze vorm van communicatie” volgt, worden de kosten sterk naar beneden gehaald. In het kort gezegd:

6

standaardistatie biedt een systeem die door iedereen interpreteerbaar is en die de communicatie en interoperabiliteit tussen verschillende systemen verhoogt. Door deze verhoging dalen de globale kosten. Standaardisatie is dus onmisbaar voor DRM, omdat het streeft naar een globaal erkend systeem. In het kader van DRM zijn er verschillende groeperingen die standaarden naar voor schuiven in de hoop dat ze aanvaard worden om in de toekomst te worden gebruikt. Die standaarden vinden we terug bij verschillende aspecten van het DRM systeem: identificatie van objecten (DOI [10], URI [60], ISTC [29]), modellering van objecten (INDECS [30], IFLA [27]), beschrijving van objecten (ONIX [20], IMS [26], VCARD [51]. Ook op het gebied van Rights Expression Languages vinden we verschillende talen terug die meedoen aan de “race” om de standaard REL te worden (XrML [6], MPEG-21 REL [38], ODRL [39], LicenseScript [33],...).

1.2

Voor- en nadelen DRM

In dit puntje zal ik de voor- en nadelen bespreken van DRM, zowel uit het gezichtspunt van de industrie als uit het gezichtspunt van de consument (gebruiker). Ook wordt ingegaan op een aantal algemene economische gevolgen.

1.2.1

Voordelen

Industrie 1. Veilige verspreiding van betrouwbare informatie: wanneer informatie die geheim of geclassificeerd is (bijvoorbeeld financi¨ele resultaten) moet doorgespeeld worden aan andere afdelingen binnen een bedrijf, zou men m.b.v DRM deze informatie veiliger kunnen verzenden. Men kan dan bijvoorbeeld ook gaan bepalen wie de informatie mag lezen door dit op te nemen in een licentie. Dit voordeel kan ook ruimer gezien worden: universiteiten kunnen wetenschappelijke resultaten op een veilige manier met elkaar delen, ... Op deze manier krijgt men dus een grotere bescherming van de data. 2. Defini¨ eren van nieuwe businessmodellen: door het gebruik van rights expression languages kan men, naargelang het beoogde 7

doel, verschillende soorten gebruikersrechten gaan defini¨eren. Deze rechten openen perspectieven voor nieuwe business modellen. Een aantal voorbeelden zijn: (a) verhuring: de consument kan voor een bepaalde tijd gebruik maken van data; (b) inschrijving: de consument betaalt lidgeld waarna hij bepaalde data kan downloaden; (c) eigendomsrechten: de consument kan eigendomsrechten over bepaalde data gaan kopen; (d) betaling per raadpleging: de consument betaalt telkens hij de data raadpleegt; (e) voorbeeldweergave: dit business model heeft vooral met marketing te maken, de consument kan bijvoorbeeld gratis de eerste 20 pagina’s van een boek bekijken. Op die manier kan men de interesse van de consument aanwakkeren en de aankoop gaan stimuleren; (f) mogelijkheid tot opdelen van een digitaal object in verschillende delen die apart kunnen beschikbaar gesteld worden aan de consument. 3. Opsporen van data: bedrijven kunnen door middel van een ingebouwd tracking mechanisme in het DRM systeem nagaan hoeveel keer een bepaald data object geraadpleegd werd of verkocht werd. Op deze manier kunnen ze statistieken bijhouden over de evolutie van hun verkoopscijfers en kunnen ze betere toekomstige beslissingen nemen. Men kan bijvoorbeeld ook informatie inwinnen omtrent de aard van de consumenten, hun koopgedrag,... 4. Minder transportkosten (alles gebeurt op de digitale snelweg). 5. Grotere inkomsten. 6. Minder tijdsverlies doordat het effectieve onderhandelen met tussenpersonen beperkt wordt. 7. Groter bereik en grotere service voor de consumenten. Men kan producten sneller verspreiden en het contact met de klant wordt ook persoonlijker.

8

Consument 1. Producten van hogere kwaliteit: door het feit dat bedrijven kunnen besparen op bvb. transportkosten, kunnen ze meer geld uitgeven aan de ontwikkeling en research van hun producten. Het kan evenwel zijn dat bedrijven dit niet doen, om zo nog meer winst te maken. Een andere reden waarom de kwaliteit kan verhogen is de vergroting van het bereik van bedrijven. Hierdoor ontstaat een grotere concurrentie. Om deze concurrentie te overleven is het vergroten van de kwaliteit een belangrijke factor. 2. Betere service: door het “tracking” mechanisme kan de producent zich beter aanpassen aan de noden en wensen van zijn cli¨enten en hen zo een betere service aanbieden. 3. De consument kan beschikken over een veiliger systeem (zie Microsoft NGSCB [35]).

1.2.2

Nadelen

Industrie 1. Initieel hoge kosten voor implementatie DRM systeem (overgang naar DRM). Consument 1. Beperking vrijheid consument: de producent kan zelf gaan bepalen welke rechten een gebruiker bvb. kan krijgen. Hij beschikt over zeer veel macht, waardoor de kans bestaat dat de consument in een sterke greep gehouden wordt. Het kan ook gebeuren dat de producent verplichtingen oplegt aan de consument die buiten de wet 5 (of de copyright) gerekend zijn. Om dit aan banden te leggen moeten er voorzieningen binnen het DRM systeem gebeuren. Zowel op architecturaal gebied als op het gebied van “Rights Expression Languages” doet men op dit gebied onderzoek.6 5 6

Fair Use, First Sale, WIPO, DMCA. zie hoofdstukken 2 en 3.

9

1.2.3

Economische gevolgen

1. Kans op monopolievorming: door de standaardisatie binnen DRM zullen slechts enkele grote standaarden overblijven: we zullen bijvoorbeeld slechts ´e´en (of weinig) rights expression language(s) hebben, een aantal bestandsformaten zouden kunnen vastliggen, ... Hierdoor zouden we evolueren naar een gering aantal grote bedrijven. Andere (kleine) bedrijven zouden de kans niet meer krijgen om hun ontwikkelingen door te voeren. Deze zouden immers toch niet kunnen overleven omdat alles naar het model van een bepaalde standaard zou moeten gemaakt worden. Ook is het zo dat kleinere bedrijven gericht zijn op deelaspecten van DRM (zoals antivirus, spam,...) Door het feit dat er een globaal systeem zou zijn dat al deze services omvat, zouden de overlevingskansen van deze kleine bedrijven achteruit gaan. Een illustratie hiervan vindt u in onderstaande figuur, die duidelijk toont dat verschillende bedrijven in de “DRM” strijd het loodje moeten leggen. 2. Minder innovatie: dit nadeel hangt nauw samen met het vorig puntje: door het feit dat men moet rekening houden met de standaarden wordt men beperkt in z’n ontwikkelingen. Men moet alles ontwikkelen met het oog op die standaard.

Figuur 1.1: Aantal DRM gerelateerde firma’s tussen 1999 en 2001

1.3

DRM en de wet

Uit de letterlijke betekenis van DRM kan men afleiden dat de wet sterk gerelateerd is aan DRM. DRM gaat immers over het beschermen van het intellectueel eigendomsrecht 10

en over het tegengaan van computerpiraterij. De wet speelt een grote rol op het gebied van DRM: 1. Als men een globaal DRM systeem wil gaan ontwikkelen, zal dit systeem erkend moeten worden door de verschillende hardware- en software-ontwikkelaars. Het zou de bedoeling zijn dat over de hele wereld bepaalde standaarden worden gehanteerd waarmee alle ontwikkelaars rekening moeten houden; eventueel moeten ze deze standaarden inbakken in hun eigen systeem. Natuurlijk is het zo dat door de grote concurrentie en het winstbejag sommige bedrijven eerder niet geneigd zullen zijn om die standaard te hanteren en liever verdergaan met hun eigen DRM gerelateerd product. Wil men dus een algemene standaard, dan zullen deze ontwikkelaars moeten verplicht worden het te implementeren. Wanneer men het in een wet vastlegt, zouden de bedrijven genoodzaakt zijn het systeem te implementeren. Omdat het aanpassen van de algemene wetten inzake het intellectueel eigendom naar digitale context niet eenvoudig is, opteert men ervoor om het digitale te scheiden van het materi¨ele en nieuwe wetten te voorzien die specifiek gericht zijn op het intellectueel eigendomsrecht in digitale context. In Amerika is er bijvoorbeeld een voorstel ingediend om zo’n wet te gaan invoeren, namelijk de SSSCA [56] (Secure Systems Standard and Certification Act). Deze wet zou de ontwikkelaars verplichten DRM features te gaan opnemen in hun producten. De DRM standaard die gebruikt moet worden zou door overleg in de industrie moeten vastgelegd worden, of indien er niet tot een besluit gekomen wordt, zou de regering kunnen tussenkomen. Het goedkeuren van deze wet zou nog altijd niet tot een goede oplossing leiden omdat ze enkel beperkt is tot Amerika: de standaard moet ook in andere gebieden buiten Amerika gehanteerd worden. Men kan dit probleem vergelijken met de DVD regio codes, waar men ook standaarden zoals NTSC en PAL heeft ingevoerd om de standaardisatie te bevorderen. 2. Zoals eerder aangehaald, speelt de wet een belangrijke rol op het gebied van Rights Expression Languages. De wet moet ervoor zorgen dat de macht van de producent niet te groot wordt, de producent zou bijvoorbeeld bepaalde rechten op gebruik van een object kunnen beperken, hoewel die rechten zijn opgenomen in de wet (hierbij denk ik aan Fair Use7 en First Sale8 ). 7 8

Gebruik van data voor educatieve doeleinden. Men mag altijd ´e´en kopie hebben voor eigen gebruik van een aangekocht object.

11

3. Op het gebied van beveiliging neemt de wet eveneens een voorname plaats in. Ze kan bijvoorbeeld verbieden dat hackers programma’s (tools) of informatie verspreiden die kunnen gebruikt worden om de toegang tot data te kraken. Dit zou interessant zijn omdat op deze manier de gewone gebruiker geen gebruik zou kunnen maken van de door de hacker verspreide gesofisticeerde tools. Op die manier zou enkel de hacker de gegevens kunnen kraken, waardoor het aantal ongerechtigde inbraken zou verminderen. Momenteel zijn er zowel in Amerika als in Europa wetten die de tools als illegaal bestempelen: In Amerika is er de “Digital Millennium Copyright Act” (DMCA) [9] die het verspreiden van tools verbiedt, in Europa hebben we de EU “Copyright Directive” [21]. Deze laatste wet verbiedt het aanmaken, verkopen, adverteren en commercieel gebruik van dergelijk tools. De DMCA is iets strenger dan de EU Copyright Directive: het verbiedt ook het verspreiden van informatie i.v.m. deze tools. Ook hier hebben we het probleem dat dergelijke wetten wereldwijd moeten nageleefd worden.

1.4

Conclusie

Er zijn verschillende beschrijvingen mogelijk om het ruim concept “DRM” te beschrijven. Digital Rights Management bestaat enerzijds uit beveiligingstechnieken (zowel op softals hardwareniveau) voor data en anderzijds uit mechanismen om data te identificeren, te beschrijven en te beschermen door het afdwingen van intellectuele eigendomsrechten. DRM streeft naar het ontwikkelen van een veilig systeem, waarin digitale objecten veilig en snel kunnen uitgewisseld worden tussen producent en consument. DRM werd ingevoerd om immateri¨ele data te kunnen beschermen. Ze heeft vooral haar nut voor de industrie, die haar content op een veilige manier wil verspreiden en een remedie zoekt tegen computerpiraterij. Daarnaast kan DRM ook gebruikt worden voor niet-commerci¨ele doeleinden zoals het beschermen van data van een eindgebruiker of data binnen een bedrijf. Om tot een goed systeem te komen is het concept “standaardisatie” alom aanwezig in de wereld van DRM. Standaardisatie bevordert de communicatie en interoperabiliteit tussen verschillende DRM architecturen en zorgt voor een globale kostenverlaging. 12

Men zou kunnen argumenteren dat het vooral de industrie is die voordeel haalt uit het gebruik van DRM en dat de consument eerder benadeeld wordt. Het gebruik van DRM kent ook een aantal economische gevolgen, waarvan de belangrijkste monopolievorming is. DRM is sterk gerelateerd met de wet: zonder de wet kan DRM niet ingevoerd worden. De wet speelt ook een belangrijke rol in het verminderen van de macht van de producent en op het gebied van beveiliging.

13

Hoofdstuk 2 Rights Expression Languages 2.1

Inleiding

Een rights expression language (REL) is een taal die dient om rechten op (digitale) objecten te specificeren en de controle op het gebruik van deze objecten te vergroten. Hiertoe maakt ze gebruik van een eigen vocabularium en grammatica. Het vocabularium wordt gespecificeerd door een woordenboek (“dictionary”), die naast de definitie van gebruikte termen ook de mapping van termen tussen verschillende systemen verzorgt (men spreekt van een RDD, een Rights Data Dictionary). Tot op heden zijn er verschillende RELs ontwikkeld, en met het oog op standaardisatie proberen verschillende groeperingen hun eigen REL naar voor te brengen als nieuwe standaard. RELs werden noodzakelijk door de hogere eisen van een tweede generatie DRM systeem. In dit hoofdstuk worden eerst een aantal bestaande RELs onder de loep genomen. Hierbij zal ik ze kort bespreken (situering, architectuur, mogelijkheden) en ook hun werking toelichten met een voorbeeld. Na een vergelijking (afweging voor- en nadelen) ga ik over tot het vooropstellen van een hypothetische, ideale REL. Als afsluiter bespreek ik nog het probleem tussen RELs en copyright. Ook ga ik het concept “Rights Data Dictionary” wat van naderbij gaan toelichten.

14

2.2 2.2.1

Studie naar bestaande RELs Inleiding

Volgende RELs worden van nabij bekeken: ODRL [39] Open Digital Rights Language. XrML [6] Extended Rights Markup Language. MPEG-21 REL [38] MPEG-21 Rights Expression Language. LS [33] LicenseScript. Verder zal ik ook nog XMCL en PRISM/PRL kort belichten.

2.2.2

ODRL

Inleiding ODRL [39] of voluit The Open Digital Rights Language is een op XML gebaseerde REL die wordt ondersteund door een aantal grote bedrijven. ODRL heeft een goed onderbouwde structuur en beschikt over tal van beveiligingsmogelijkheden. ODRL beschikt ook over z’n eigen data dictionary. Structuur en mogelijkheden [40] Deze taal bestaat uit een aantal modellen die de structuur en de semantiek van de expressies vastleggen. Met behulp van deze modellen kunnen “rights expressions”gevormd worden met termen uit de data dictionary. Volgende modellen zijn aanwezig: 1. Foundation Model: het “hoofdmodel”, definieert de 3 core entiteiten (party, asset, right) die kunnen gebruikt worden om offers en agreements te defini¨eren. Een party kan zowel een end user(consument) zijn als een rights holder (producent). Een asset is het object waarover rechten (rights) kunnen gedefinieerd worden, het kan zowel digitale als 15

Figuur 2.1: ODRL Foundation Model (Basis van ODRL) [24]

niet-digitale content voorstellen. Een asset moet uniek ge¨ıdentificeerd worden en kan ook ge¨encrypteerd worden. De rights zijn de rechten die men over een asset kan defini¨eren. 2. Permission Model: definieert de “toelatingen” (rechten) op het gebruik van een asset. <print> ... 3. Constraint Model: definieert beperkingen op de permissions (voorbeeld: een document mag 5 keer afgedrukt worden). <print> 5 16

4. Requirement Model: definieert verplichtingen op de permissions. Dit zijn condities die waar moeten zijn alvorens men rechten verkrijgt op het gebruik van een object. In het onderstaand voorbeeld moet men bijvoorbeeld 20 AUD betalen alvorens men het object mag afspelen. <requirement> <payment> 20.00 5. Condition Model: definieert een “versterkte versie”van een constraint. Wanneer de conditie waar is, vervallen alle permissions op het gebruik van het asset. 6. Rights Holder Model: definieert een aantal entiteiten met betrekking tot de rights holder. 7. Context Model: wordt gebruikt voor identificatie en ook om de entiteiten met elkaar te linken. Het wordt ook gebruikt om entiteiten te beschrijven. 8. Offer Model: een offer definieert een “voorstel” van een aantal rechten tot gebruik van een asset. Ze wordt gepresenteerd aan de end user waarna hij kan beslissen de offer al of niet aan te nemen. Dit model is interessant omdat het de keuzemogelijkheden van de end user kan vergroten. 9. Agreement Model: ´e´enmaal de end user een offer goedkeurt, spreekt men van een agreement en wordt de offer omgezet in een licentie.

17

10. Revoke Model: wordt gebruikt om reeds gedefinieerde structuren (licenties, rechten) terug op te roepen. Het Revoke model maakt gebruik van het Context model. 11. Security Model: met dit model kunnen “digital signatures” gedefinieerd worden voor rights expressions en kan men ook encryptie van assets voorzien. Om dit te realiseren steunt dit model op W3C [62] Digital Signature (DSIG) [15] en W3C XML Encryption (XML-ENC) [69]. Mogelijkheden Naast deze modellen biedt ODRL ook nog een aantal bijkomstige mogelijkheden die handig kunnen zijn bij het eigenlijk defini¨eren van een ODRL document. Expression containers: om entiteiten bij elkaar te groeperen. Sequence: totale of parti¨ele ordening van entiteiten. Linking: kan o.m. gebruikt worden om te refereren naar entiteiten. Inheritance: overerving van rechten van de ene naar de andere asset. Data Dictionary De data dictionary omvat de definitie van volgende elementen die kunnen gebruikt worden in ODRL expressies: 1. Permission elements 2. Constraints elements 3. Requirement elements 4. Rights Holder elements 5. Context elements Uitbreidbaarheid In ODRL kan men gemakkelijk de Data Dictionary uitbreiden als men bijvoorbeeld zelf-gedefinieerde elementen wil gaan gebruiken in ODRL-expressies. Dit gebeurt door een 18

nieuw XML schema te defini¨eren die de ODRL expression language schema importeert. In dit nieuwe XML schema kan men dan bijkomende definities declareren van de abstracte entiteiten. Later kan men dit schema dan gebruiken als validering van het document, net zoals men het standaard ODRL Expression Language schema zou gebruiken. Besluit ODRL is een op XML gebaseerde REL die zeer flexibel is, ze kan overal ingeplugd worden en beschikt over een grote interoperabiliteit. Ze biedt mogelijkheden voor beveiliging en encryptie en is ook uitbreidbaar. Een aantal interessante features zorgen ervoor dat de auteur van een ODRL document op een gemakkelijke manier ingewikkelde documenten (offers, agreement) kan aanmaken. Dit laat onder meer de gebruiker toe te kiezen tussen alternatieven alvorens een licentie aan te gaan. Door aanwezigheid van het context model beschikt ODRL ook over een ruim identificatiesysteem.

2.2.3

XrML

Inleiding XrML [6] of voluit Extended Rights Markup Language werd ontwikkeld door XeroX PARC [68]. Ze werd uitgebracht in 1999 als opvolger van DPRL (Digital Property Rights Language) [11]. Het steunt op XML Schema [22] (zowel voor z’n syntax als andere features), daar waar z’n voorganger een lisp-style metalanguage1 was. XrML wordt door veel standaardisatie-groeperingen (zoals MPEG [36],OEBF [41],OASIS [42]) gebruikt en werd geadapteerd door ContentGuard [8]. Structuur en mogelijkheden [72] Data Model XrML heeft een uitbreidbaar data model dat bestaat uit 4 entiteiten en de relaties tussen die entiteiten. De basisstructuur is de grant: de principal krijgt de rights op de 1

LISP (LISt Processing) is samen met Fortran ´e´en van de oudste hogere programmeertalen. De taal werd eind jaren vijftig door John McCarthy (een van de founding fathers van de AI) ontworpen als een taal voor het beschrijven en oplossen van symbolische wiskundige problemen. Lisp is een declaratieve taal.

19

resource onder bepaalde conditions. De meeste entiteiten zijn abstract en kunnen net zoals in ODRL door uitbreiding concreet gemaakt worden. In een digitale context kan bvb. right uitgebreid worden met copy.

Figuur 2.2: XrML Data Model

De “Principal” is degene aan wie de rechten toegekend worden. De “Rights” zijn de rechten die gedefinieerd kunnen worden. De “Resource” is het object (al of niet digitaal) waarop rechten gedefinieerd kunnen worden. De “Conditions” zijn de voorwaarden waaraan moet voldaan worden vooraleer Rights kunnen uitgevoerd worden. XrML bestaat uit een aantal Basic Data Constructs, met name de grant en de license. Een license bestaat uit 1 of meerdere grants, die op hun beurt bestaan uit een principal, een right, een resource en een condition. Eventueel kan ook nog een issuer gedeclareerd worden, dit is de “uitgever” van de license. De issuers worden ge¨ıdentificeerd, de principals die in de grants zitten niet, aangezien zij al in de construct “grant ”ge¨ıdentificeerd werden.

Figuur 2.3: XrML basic data construct

20

Core, Standard Extension en Content Extension De structuur van XrML is als volgt georganiseerd: 1. Core Schema: vormt het hart van XrML, bevat de minimale termen die nodig zijn om basic constructs aan te maken. De belangrijkste zijn de license, grant, resource, right, condition en principal. De 4 laatstgenoemde zijn abstract, ze moeten gesubstitueerd worden door een concrete term. (Vb Principal = keyHolder). 2. Standard Extension: breidt het condition type van het “Core Schema” uit met o.a. time- en payment conditions. 3. Content Extension: definieert nieuwe termen ter ondersteuning van digitale objecten. 4. Other Extension Schema’s: user-gedefinieerde schema’s die kunnen gebruikt worden om specifieke uitbreidingen aan het “Core Schema” te breien.

Figuur 2.4: XrML structuur

Mogelijkheden XrML biedt betrouwbaarheid, veiligheid en ook mogelijkheden voor web services door te steunen op in XML aanwezige structuren. 1. Betrouwbaarheid: XrML definieert EncryptedLicense en EncryptedGrant die steunen op XML Encryption Syntax en Processing Standard. 21

2. Web services: het element ”ServiceReference ”(steunt op WSDL [63] UDDI [61]) biedt verschillende mogelijkheden voor web services. 3. Pattern matching: systeem om sets van entiteiten te kunnen defini¨eren. Besluit XrML is simpel en makkelijk te begrijpen, het steunt op XML syntax, wat de interoperabiliteit met andere systemen sterk verhoogt. Ze is vrij uitbreidbaar (men kan gemakkelijk schema’s defini¨eren) en dus ook geschikt voor verschillende soorten business models (DRM systemen, digitale data, database systemen).

2.2.4

MPEG-21 REL

Inleiding MPEG-21 REL [38]2 of voluit MPEG-21 Rights Expression Language steunt op XrML, die hierboven beschreven werd. Het is een onderdeel van het MPEG-21 framework, meer specifiek Part 5. Het heeft dus dezelfde architectuur en semantiek als XrML, maar op het gebied van permissions werd er nog bijkomende semantiek toegevoegd. Deze taal is dus minder “zelfstandig” dan bijvoorbeeld ODRL, omdat het steunt op een reeds bestaande REL, maar dit is de normale manier van werken binnen de MPEG-21 groep. MPEG-21 REL beschikt ook over zijn eigen data dictionary nl. MPEG-21 RDD. Structuur en mogelijkheden [57] Dezelfde structuur en mogelijkheden zoals beschreven in XrML zijn aanwezig. De taal is zeer geschikt voor het defini¨eren van verschillende business models. MPEG-21 REL ondersteunt o.a. de aanmaak van volgende constructies: 1. Usage License: laat toe om gebruikersrechten te defini¨eren op een resource, met eventueel bijkomende conditions. Dit is de meest eenvoudige licentie. 2

Recent werd MPEG-21 REL herkend door de ISO groepering waardoor het de naam “ISO MPEG REL” kreeg[18].

22

2. Distribution License: laat toe een licentie voor tussenliggende verdeler te defini¨eren. Een verdeler is een entiteit die zich tussen de producent en de consument bevindt in de ”supply chain ”. Deze licentie kan bijvoorbeeld bepalen welke licenties de distributor mag defini¨eren voor consumers. 3. Offer License: deze licentie definieert een “Offer” (een voorstel van een licentie). De gebruiker kan deze “Offer” bekijken, en als hij akkoord gaat met de in de “Offer” gedeclareerde voorwaarden, kan een licentie aangemaakt worden horende bij de “Offer”. 4. Membership Certificate: licentie die door de end-user gebruikt wordt om te tonen dat hij in bezit is van een bepaalde “property ”(bvb. dat hij lid is van een groep). 5. Membership Offer License: licentie die gebruikt kan worden om verschillende soorten van lidmaatschap voor te stellen aan een eindgebruiker. Een handige tool om MPEG-21 REL licenties aan te maken is RightsExpress [52], een web-interface ontwikkeld door ContentGuard. De gebruiker kan gegevens invoeren zoals de rechten die moeten gedefinieerd worden,wat de resource is, wie de rechten krijgt... RightsExpress zal dan deze gegevens verwerken tot een MPEG-21 REL licentie. Besluit MPEG-21 REL is een geavanceerde versie van XrML. Het wordt door de industrie aanzien als de REL bij uitstek door z’n flexibiliteit en uitbreidingsmogelijkheden. In het kader van deze thesis zal deze taal ook een belangrijke rol spelen in het praktisch gedeelte, met name het schrijven van een MPEG-21 REL-parser.

2.2.5

LicenseScript

Inleiding LicenseScript [33] is, in tegenstelling tot de voorheen besproken RELs, niet op XML gebaseerd. Het is een logische REL, die steunt op PROLOG. Deze taal is eerder een 23

experiment (Universiteit van Twente), de kans dat deze taal ooit doorbreekt als standaard is dan ook zeer klein. Structuur en mogelijkheden Structuur LicenseScript steunt op “multiset rewriting” (wordt gebruikt voor dynamische evolutie van licenties) en op logisch programmeren voor de definitie van de termen in een licentie. Een licentie bestaat uit een “content ”(d.i. het object waarover rechten worden gedefinieerd), “bindings ”(deze stellen de attributen voor van de licentie) en de “clauses ”(dit zijn clausules die bepalen wanneer een operatie al dan niet is toegestaan). Licenties zijn gebonden aan de termen die opgenomen zijn in multisets. De algemene gedaante van een licentie is license(content,C,B) waarbij content het object voortstelt, C de lijst is met clausules en B de lijst is met bindings.

Figuur 2.5: LicenseScript: transformatie van licenties

LicenseScript werkt als volgt: als een persoon een operatie wil doen (bvb. een “print”van een e-book), wordt er eerst gezocht naar een “rule”die hiervoor instaat. Deze rule zal eerst zoeken als er een licentie aanwezig is in het systeem voor het opgegeven object. Deze rule zal dan de gegevens in de clausules controleren aan de hand van de opgegeven parameters en zal ook de bindings opgenomen in de licentie testen op validiteit. Deze bindings kunnen gebruikt worden voor identificatie en ook voor het bijhouden van een aantal voorwaarden (bvb. het maximum aantal toegelaten prints). Wanneer de regels opgenomen in de clausules voldaan zijn, wordt een nieuwe licentie aangemaakt door de bindings aan te passen (bvb. aantal keer dat je mag afdrukken met ´e´en verlagen). Op

24

deze manier zal een nieuwe licentie gecre¨eerd worden met aangepaste (upgedate) attributen (bindings): license(content,C1,B1) wordt license(content,C1,B2).

Mogelijkheden 1. Authentificatie: kan gebeuren door te vergelijken met de waarden van de bindings. 2. licentie - evolutie : door het dynamisch karakter kan men de evolutie van licenties van nabij beschouwen. 3. Dynamische modellering: omdat in LicenseScript “licenties”worden getransformeerd, is het eenvoudig om bijvoorbeeld een offer om te zetten in een licentie. 4. Concurrente toegang: wanneer 2 entiteiten tegelijkertijd aanspraak willen doen op een resource kan men door bindings te defini¨eren de voorrang geven aan 1 van die entiteiten (bvb. bij gedeelde documenten ). 5. Bijhouden van een historiek: door het telkens aanpassen van een “binding history”. 6. Uitbreidbaarheid: een entiteit kan gemakkelijk zijn eigen attributen toevoegen aan een licentie, mits dit toegelaten is. 7. Status constraint: deze beperking kijkt als data beschikbaar is op het moment dat rechten erop uitgevoerd worden (kan bijvoorbeeld gebruikt worden in ware-tijdssystemen). 8. Onderhouden van rechten (rights regulation): er zijn mechanismen aanwezig waardoor een gebruiker z’n rechten kan vernieuwen. Besluit LicenseScript is een alternatieve REL die steunt op logische taal in plaats van XML. Hoewel ze moeilijker te gebruiken is (er is voorkennis vereist van logisch programmeren), biedt deze taal toch veel mogelijkheden (zoals licentie-evolutie, het oplossen van conflicten

25

bij concurrente toegang, status beperking) die we in andere talen niet terugvinden. Voor een concrete vergelijking verwijs ik graag naar “Vergelijking RELs ”. Voorbeelden van deze laatst besproken RELs zijn terug te vinden op het einde van dit hoofdstuk.

2.2.6

Andere RELs

Naast ODRL, XrML, MPEG-21 REL en LicenseScript bestaan er ook nog andere RELs. Ik ga ze hier kort belichten ter vervollediging. PRISM/PRL PRISM of voluit Publishing Requirements for Industry Standard Metadata [44] is een uitbreidbare XML metadata standard die oorspronkelijk diende om content uit de magazine industrie te controleren en te onderhouden. PRISM maakt o.a. gebruik van reeds bestaande standaards zoals RDF (“Resource Description Framework”) [50], Dublin Core [19] (voor meta-data). Uit PRISM is dan PRL [43] ontstaan, een bescheiden “rights language” die een beperkt aantal elementen met betrekking tot het defini¨eren van rechten ondersteunt. PRL wordt gebruikt in systemen waar controle over de rechten van data moet gebeuren, het is echter geen volwaardige REL, het ondersteunt bvb. geen beleidsovereenkomsten (“policy”) en betalingsstructuren. Het kan gebruikt worden in systemen waar enkel basisvereisten nodig zijn i.v.m. rechten. XMCL XMCL of voluit Extended media Commerce Language [23] is een op XML gebaseerde REL die niet zo ruim is als andere RELs zoals XrML en ODRL. Het is vooral geconcentreerd op een aantal businessmodellen (verhuring, inschrijving, defini¨eren van eigendomsrechten, betalen per raadpleging).

2.3

Vergelijking RELs

In deze sectie zal ik de voorheen besproken RELs met elkaar vergelijken.

26

2.3.1

Vergelijking XML-gebaseerde RELs onderling [49]

Na het bestuderen van ODRL, XrML, MPEG-21 REL heb ik ondervonden dat deze talen eigenlijk niet zo erg veel van elkaar verschillen: de grootste reden daarvoor is dat ze allemaal gesteund zijn op XML ( ze steunen op dezelfde “features” voor hun mogelijkheden). Omdat MPEG-21 REL gebaseerd is op XrML, zal ik deze 2 talen als ´e´en REL beschouwen. Ik had de indruk dat ODRL beter onderbouwd is dan MPEG-21 REL, vooral op het gebied van “syntactische mogelijkheden”(gebruik van sequenties, linking, overerving). Bovendien biedt ODRL ook veel beschrijvingsmogelijkheden door aanwezigheid van een Context Model. Beide talen zijn flexibel, uitbreidbaar en staan open voor gebruik in andere contexten. Tevens kan men ook verschillende businessmodellen implementeren. Deze businessmodellen zijn meer expliciet aanwezig in MPEG-21 REL.

2.3.2

Vergelijking XML-gebaseerde RELs en logisch gebaseerde REL LicenseScript [5]

Het grootste nadeel van XML-gebaseerde RELs is dat er geen vaste formele semantiek aanwezig is: XML syntax is te “menselijk” en voor interpretatie vatbaar (“human interpretable”). Daarbij komt ook nog dat XML syntax zeer complex wordt naarmate de constructies ingewikkelder worden. LicenseScript daarentegen steunt op logische taal, ze is veel formeler van aard en meer machine-taal gericht. Een nadeel van deze formele aanpak is wel dat de gebruiker enige voorkennis moet hebben van “logisch programmeren ”. LicenseScript biedt ook meer mogelijkheden dan ODRL en MPEG-21 REL. Men kan additionele beperkingen zoals het “status constraint” defini¨eren en ook het onderhouden van rechten is beter in LicenseScript. Door de sterke aanwezigheid van transformatie van licenties in LicenseScript, kan men ook aan dynamische modellering doen en de evolutie van licenties van dichtbij volgen. Op het gebied van beveiliging, authentificatie en identificatie is LicenseScript dan weer zwakker dan ODRL en MPEG-21 REL. ODLR en MPEG-21 REL zijn sterker op het gebied van interoperabiliteit, omdat ze steunen op de alom aanwezige en gekende XML. In volgende tabel ziet u de mogelijkheden van elke taal 27

samengevat. “*” betekent dat de mogelijkheid aanwezig is.

Generaliteit Identificatie van resources Rechten voor digitale content Weergave (render) Hergebruik (reuse) Transport Onderhouden resources Onderhouden rechten Beperkingen Temporeel Begrenzing aantal Begrenzing territoriaal Aspecten van resources Doel Status Kenmerken (features) Beveiliging Authentificatie Importeren van metadata Betrouwbaarheid Interoperabiliteit Keuzemogelijkheden gebruiker Ondersteuning businessmodellen Uitbreidbaarheid Copyright Niet-commerciele doeleinden

XrML/ MPEG-21 REL * * (met XML DSIG)

ODRL * * (met XML DSIG)

LicenseScript * * (bindings)

* * * * (revocation)

* * * * (revocation)

* * * * *

* * * *

* * * * *

* * * * * *

* * * * * * *

* * * * * * *

* (beperkt) * * * * *

*

*

*

Tabel 2.1: Vergelijking RELs.

2.4

Voorstelling van een hypothetische REL

Steunend op de voor- en nadelen bij m’n onderzoek van RELs zal ik nu een hypothetische ideale REL vooropstellen.

28

2.4.1

Structuur

De REL moet volgende basis-entiteiten defini¨eren: 1. Onderwerp: de entiteit die operaties uitvoert op een object. 2. Object: de entiteit waarover rechten worden gedefinieerd. 3. Operatie: de operatie die een onderwerp kan uitvoeren op een object (d.i. het recht). 4. Beperking: definieert een beperking op het gebruik van een object of een conditie waaraan moet voldaan worden alvorens een operatie op het object kan uitgevoerd worden. Met deze basis-eniteiten bekomt men volgende basis-construct: Een onderwerp voert operaties uit op een object rekening houdend met bepaalde beperkingen. Onderwerp Het Onderwerp moet zo gedefinieerd worden dat ook groepen van entiteiten als een onderwerp kunnen fungeren. Object De REL moet rekening houden met verschillende soorten objecten (digitaal, fysisch), ze moet dus uitgaan van een bepaalde generaliteit. Operaties en beperkingen Ook hier moet generaliteit voorzien zijn. De beperkingen moeten een heel complex karakter kunnen hebben. Ze moeten niet enkel condities voorstellen maar ook “requirements” alvorens een operatie kan worden uitgevoerd. Deze “requirements” worden gecontroleerd nog voor de condities gecontroleerd worden, ze bieden een extra controle.

2.4.2

Mogelijkheden

De REL moet voldoen aan volgende zaken:

29

1. alle voorzieningen (“features”) opgenomen in de tabel (voor sommige features is dit momenteel onmogelijk, zie huidig onderzoek); 2. ze moet steunen op een standaard, om de interoperabiliteit tussen systemen te vergroten (ze kan dan eventueel gebruik maken van (features uit de standaard); 3. ze moet makkelijk begrijpbaar zijn; 4. zowel simpele als complexe REL statements moeten kunnen gedeclareerd worden; 5. de REL zelf moet gestructureerd zijn en goed onderbouwd (programmeeraspecten); 6. ze moet uitbreidbaar zijn naar specifieke contexten; 7. ze moet beschikken over een uitgebreide data dictionary; 8. ze moet beschikken over een goed identificatiesysteem voor het identificeren van onderwerpen en objecten.

2.5

REL en copyright

Het grote probleem bij RELs is dat het een “permission”taal is. De producent bepaalt welke rechten er opgenomen worden in de licentie en daardoor kan hij een grote macht krijgen over de consument, waardoor de balans tussen beide verstoord wordt. Hierdoor kan het bijvoorbeeld gebeuren dat de producent bepaalde rechten tot gebruik beperkt of restricties oplegt op het gebruik van een object, die tegen het wettelijk gebruik ingaan. Om te voorkomen dat hij een grotere macht krijgt dan de wet onderzoekt men nu hoe men RELs zou kunnen aanpassen, zodanig dat toch nog met de wet rekening gehouden wordt. Een consument zou bijvoorbeeld aan een licentie gemakkelijk z’n eigen rechten moeten kunnen toevoegen. Hierbij denkt men vooral aan de “Fair Use” en “First Sale” wetten. Ook op architecturaal vlak doet men onderzoek om dit probleem aan te pakken. Dit probleem is zeer ingewikkeld omdat wetten in het algemeen nogal breed kunnen ge¨ınterpreteerd worden en dat het vastleggen van deze wetten niet zo gemakkelijk is in computersystemen.

30

2.6

Rights Data Dictionary

Zoals in de inleiding aangehaald, heeft een REL nood aan een aantal termen, zodanig dat men rechtsexpressies kan maken. Deze termen worden gebundeld in een RDD, een “Rights Data Dictionary”. Deze RDD bevat alle mogelijke termen die kunnen gebruikt worden in een REL uitdrukking. De termen hebben hun eigen betekenis en zijn aan elkaar gerelateerd. Door deze relaties ontstaat er een gestructureerde hi¨erarchie, die een mooi overzicht heeft hoe de termen in een licentie kunnen gebruikt worden (bijvoorbeeld wat zijn de concrete termen die kunnen ingevuld worden in een abstracte term?). Het vocabularium is ´e´en gesloten geheel of “ontology”. De betekenis die aan een term wordt gegeven ligt vast in het systeem en is onafhankelijk van andere (misschien meer logische of algemeen aanvaarde) betekenissen in andere systemen. Hier komt de tweede functie van een RDD tot z’n recht: het zorgt dat systemen elkaars termen op een goede manier kunnen interpreteren door “mapping”. Deze “afbeelding” staat ook in voor het toevoegen van nieuwe termen. Er bestaat software om termen te gaan opzoeken en hun relatie (genealogy) met andere termen te gaan weergeven.

2.7

Voorbeelden

In deze sectie zal ik van de voornaamste RELs kort een voorbeeld bespreken.3

2.7.1

XML gebaseerde RELs

XrML en MPEG-21 REL Omdat XrML de basis is van MPEG-21 REL, zal ik ze hier samen bespreken. Een handig hulpmiddel om MPEG-21 REL (XrML) licenties aan te maken is RightsExpress.

Uitleg De licentie begint met de “license” tag, wat naast licenseGroup, de hoogste tag is in de hi¨erarchie van een MPEG-21 REL document. Een licentie bestaat uit een aantal grants en eventueel een bijkomende Issuer. Daarnaast kunnen er ook nog andere elementen 3

Zie appendix C voor codefragmenten.

31

opgenomen worden in de licentie, zoals een “title” tag (titel van het REL document) of een “otherInfo” tag (bijkomende info). De “grant” tag is een basisonderdeel die moet voorkomen in de licentie. Zonder een grant te defini¨eren, kan je ook geen licentie defini¨eren. Het is de meest minimale structuur die verplicht ingevoerd moet worden. Ze bevat de abstracte elementen right, resource en condition. Deze abstracte elementen worden door substitutie ingevuld (hier bijvoorbeeld met het “print” right, en een “digitalResource” als resource. De condition wordt ingevuld met een “validityInterval”. De issuer is degene die de licentie opstelt. Eventueel kan men ook in de grant nog het abstracte element “principal” gaan invullen. Dit is de persoon die de rechten bekomt die in de licentie gedefinieerd werden. De issuer kan beschreven worden d.m.v. gebruik van het abstracte principal object, of hij kan ook z’n digitale handtekening zetten. In deze licentie zien we dat er geen principal gedefinieerd is in de grant, dit betekent dat iedereen die de licentie verkrijgt, de rechten mag uitvoeren die gedefinieerd staan in die licentie. Deze licentie stelt kort het volgende voor: iedereen mag het boek die zich bevindt op de gedefinieerde URI printen op voorwaarde dat dit gebeurt voor 24-12-2002 om 23:59:59 (dus voor Kerstmis 2002). Wanneer iemand probeert het boek te printen nadat het tijdsinterval verstreken is, zal dit niet meer gaan. Merk op dat MPEG-21 REL uit 3 schema’s bestaat: het Core-, het Standard Extensionen het Multimedia Extension schema: dit kan je zien aan de prefixen die gebruikt worden. (r: staat voor de Core, sx: staat voor de Standard Extension, mx: staat voor de Multimedia Extension). Er kan ook gebruik gemaakt worden van andere xml schema’s zoals “dsig” (Digital Signature)[15], “xenc” (XML encryption)[69], “Dublin Core”[19], ... Dit voorbeeld is zeer eenvoudig; MPEG-21 REL laat toe zeer geavanceerde licenties te defini¨eren. Hiervoor verwijs ik graag naar RightsExpress[52], een web-interface die tal van voorbeeldlicenties bevat en waar u ook zelf licenties kan aanmaken. ODRL Uitleg Dit ODRL fragment stelt een “Offer” voor. Het is een voorstel tot gebruik van een bepaald object, dat aan de consument kan voorgelegd worden. Deze consument kan dan eventueel instemmen m.b.v. een Agreement.

32

Concreet stelt dit ODRL fragment het volgende voor: een auteur (Corky Rossi) wenst een offer te publiceren naar cli¨enten toe. Een cli¨ent kan de eerste 2 pagina’s van het e-book bekijken, die beperkt is tot gebruik op ´e´en CPU, op voorwaarde dat hij eerst 20 Dollar betaalt plus een taxpercentage van 10 percent. Ook wordt er gespecificeerd dat de auteur 60 procent krijgt van de inkomsten. Eventueel kunnen hier nog andere auteurs/organisaties gedefinieerd worden die dan de andere percentages van de inkomsten krijgen. Een woordje uitleg over de constructs: Een ODRL licentie bestaat uit 3 core entities (party, asset en right). De hoofdtag is de “rights” tag, deze is vergelijkbaar met de “license” tag in MPEG-21 REL. Hier bevat de “rights” tag een “offer” tag. Een offer wordt altijd gedefinieerd over een “asset”, dit is het object waarover rechten worden gedefinieerd. In tegenstelling tot MPEG-21 REL, gebruikt men hier het context model om het object (en ook bvb. party’s) te gaan beschrijven. Naast de asset zien we ook de “permission” tag in de offer staan. Deze specificeert de rechten die de rechthebbende mag uitvoeren op het object. Hier hebben we bvb. display (men kan het werk gaan bekijken) en print (men kan het werk gaan uitprinten). Ook in ODRL zijn er dus veel rechten voorhanden met betrekking tot digitale objecten. Net zoals in XrML kan men ook bepaalde beperkingen op het uitvoeren van rechten defini¨eren. Dit doet men d.m.v. constraints. Naast de constraints bezit ODRL ook nog een krachtigere beperking, nl. de “requirement”: dit is iets dat moet voldaan zijn alvorens alle rechten kunnen uitgevoerd worden. Het zijn dus verplichtingen op de permissions. Hier bvb. moet de client eerst betalen alvorens hij de permissions kan uitvoeren. Wanneer dus aan een requirement niet voldaan is, kan de consument geen enkel recht uitvoeren. Als laatste tag hebben we de “party” tag. Deze is vergelijkbaar met de issuer bij XrML.

2.7.2

Logische REL

In dit deel ga ik een voorbeeld van LicenseScript bespreken. LicenseScript Uitleg Dit stukje LicenseScript code is geschreven in een logische taal, nl. PROLOG. Zoals eerder aangehaald bevat een niet XML-gebaseerde taal een echte formele semantiek, daar 33

waar de XML gebaseerde talen nogal menselijk interpreteerbaar zijn. Natuurlijk is LicenseScript enger in z’n gebruik: wensen we bijvoorbeeld beschrijvingen toe te voegen, dan kunnen we niet gebruik maken van metadata systemen (zelfde voor encryptie). Deze licentie zal een gebruiker, “Amanda” genaamd, toelaten om 2 kopies uit te drukken van het e-book getiteld “A Book” gepubliceerd door “Ben Publisher”. Ook werd door “Ben Publisher” een vervaldatum voor deze licentie opgenomen, nl. 23-06-2004. De eerste 14 regels in het voorbeeld (gelabeld met L...) stellen de licentie voor. Ze is van de vorm “license(content,C,B)” waarbij content een identifier is die refereert naar het object van de licentie. C is een lijst van “license clauses” (dit zijn Prolog programma’s). Deze beschrijven wanneer bepaalde operaties al of niet mogen uitgevoerd worden (vergelijkbaar met de algemene conditions). B is de lijst van “license bindings” . Deze bevat de attributen van de licentie (dus de specifieke informatie in de licentie). Het 2de gedeelte van de figuur (de regels gelabeld met R...) stellen regels voor die ingebakken zijn in het systeem. Wanneer Amanda probeert het e-book uit te drukken zal haar systeem eerst kijken of ze dit wel mag doen, door na te gaan of er in het systeem van de publisher een licentie voor Amanda aanwezig is. Om dit te weten te komen, wordt de print rule (print(ebook:abook,amanda)) uitgevoerd. Deze regel zal de algemene licentie (license(ebook:a-book,...,...)) vinden. Nu wordt een query uitgevoerd die eerst de attributen zal ophalen en dan worden deze attributen gebruikt in de license clauses om te kijken als aan alle condities voldaan is. Als dit zo is, zal de query “yes” teruggeven en zal er een nieuwe aangepaste license met nieuwe bindings gegenereerd worden. Op die manier worden de specifieke eigenschappen van de licentie aangepast (bijvoorbeeld het updaten van een print-counter). Zoals je aan de syntax van de printrule kan zien, worden de bindings (dit zijn de specifieke attributen) dus telkens aangepast.

2.8

Conclusie

Een rights expression language (REL) is een taal die dient om rechten op (digitale) objecten te specificeren en de controle op het gebruik van deze objecten te vergroten. Hiertoe beschikt ze over een eigen grammatica en vocabularium (woordenboek). Naast de XML-gebaseerde RELs (ODRL, XrML, MPEG-21 REL, XMCL en PRL), bestaat er ook een REL die op logische taal gesteund is (LicenseScript). Het moet evenwel 34

opgemerkt worden dat deze laatste REL een eerder experimentele REL is, ze is geen kandidaat om de “standaard REL” te worden. De XML-gebaseerde talen hebben veel mogelijkheden omdat ze steunen op een alom aanwezige standaard die ook gebruikt wordt bij andere mechanismen (beveiliging, metadata). Een tweede voordeel die voortvloeit uit de aanwezigheid van deze standaard is dat XML-gebaseerde talen ook een grotere interoperabiliteit verzekeren. XML-gebaseerde talen hebben evenwel ook een aantal minder goeie karaktertrekken: ze zijn te “menselijk” en syntactisch gezien kunnen ze leiden tot ingewikkelde constructies. Door het gebruik van de logische taal PROLOG beschikt LicenseScript over een formele semantiek, waardoor ze beter interpreteerbaar is door machines. Ook biedt ze mogelijkheden die niet aanwezig zijn bij de XML-gebaseerde talen, zoals licentie-evolutie. Het grootste nadeel van LicenseScript is dat het nogal “een eiland” op zichzelf is, ze kan bijvoorbeeld geen gebruik maken van andere standaarden voor bepaalde functionaliteiten.

35

Hoofdstuk 3 DRM architecturen 3.1

Inleiding

Om DRM effectief te kunnen gebruiken moet er een algemeen stelsel (framework) aanwezig zijn die de features van DRM implementeert en organiseert. Er is dus nood aan een ondersteunende architectuur. Deze architectuur moet tevens voldoen aan een aantal eisen opdat het systeem goed zou werken. In de praktijk zijn er reeds een aantal DRM systemen [13] aanwezig en het leek me dan ook interessant om hun architectuur van naderbij te bekijken. Op het einde van dit hoofdstuk zal ik een algemene architectuur vooropstellen steunend op m’n onderzoek. Ook ga ik in op het “copyright” probleem, zoals reeds aangehaald in het inleidende hoofdstuk.

3.2

Onderzoek naar architecturen in de praktijk

DRM wordt o.a. gebruikt in verschillende (multi)mediaplayers. De eigenaar van een digitaal object, bijvoorbeeld een film, kan bepalen hoeveel keer iemand die film kan bekijken, wat de kwaliteit is van de film naargelang het betaalde bedrag, ... Ik heb in mijn onderzoek verschillende (multi) mediaplayers onderzocht, waaronder Windows Media Player [65], Real Player [47] en QuickTime iTunes [45]. Naast (multi) mediaplayers vindt men DRM ook terug op andere gebieden. Een voorbeeld hiervan is Windows RMS [67], het DRM systeem van Microsoft. Dit systeem wordt gebruikt in Microsoft Office 2003.

36

3.2.1

Windows Media Player

Windows Media Player is een programma om allerlei soorten van digitale gegevens zoals mp3, mpeg, divx, audio cds, ... af te spelen. Tevens biedt het ook de mogelijkheid om online data te bekijken of te beluisteren (bijvoorbeeld Internet radio’s) . In dit geval spreekt men van “streaming”. Vooral deze laatste mogelijkheid heeft nood aan DRM: een producent kan bijvoorbeeld een “preview” van z’n film verspreiden die iedereen mag bekijken (er wordt een algemene gebruikerslicentie aangemaakt). Daarnaast kan hij ook de rest van de film in ge¨encrypteerde vorm verspreiden, die mits betaling kan gedecrypteerd worden zodat de consument de gehele film kan streamen (de consument moet dan een specifieke licentie aankopen). De gebruiker heeft dus toegang tot de ge¨encrypteerde data, die door de producent wordt verspreid. Wanneer de gebruiker deze data wil gaan gebruiken (bijvoorbeeld bekijken van de film) heeft hij nood aan een licentie. Deze licentie bevat een sleutel om de ge¨encrypteerde data te “unlocken”. Producenten kunnen verschillende licenties defini¨eren op het gebruik van data; wanneer de consument dan op een bepaalde wijze gebruik wil maken van die data, koopt hij de gepaste licentie aan. Het systeem dat zorgt voor DRM-mogelijkheden binnen Windows Media Player draagt de naam “Microsoft Windows Media Rights Manager” [66]. Architectuur [64]

Figuur 3.1: Windows Media Player: DRM architectuur

37

Uitleg Wanneer een producent z’n digitaal werk wil verspreiden, gaat hij de digitale gegevens “inpakken”. Zo’n pakket (“package”) bevat een ge¨encrypteerde versie van de digitale data . Deze digitale data wordt vergrendeld met een sleutel. De sleutel zelf moet ook aangemaakt worden en wordt verzonden in een aparte ge¨encrypteerde licentie die gebonden is aan de gegevens. De data en de licentie worden dus los van elkaar gedistribueerd. Een licentie wordt pas gedistribueerd als een consument bepaalde digitale data wil raadplegen. Andere informatie omtrent de producent (contactgegevens, URL) worden ook toegevoegd aan de digitale data. Wanneer de digitale data in een pakket zit (dus ge¨encrypteerd is), kan de producent deze vrij gaan verspreiden op het Internet of specifieker in een Intranet. Hij kan z’n gegevens bijvoorbeeld op een webserver zetten, die commercieel toegankelijk is voor consumenten. Een andere mogelijkheid bestaat erin de data op een media server te zetten zodanig dat de producent de “content” kan streamen. Zoals reeds aangehaald, wordt de licentie gescheiden van de digitale data: ze wordt op een aparte server geplaatst. Men spreekt van een “license clearing house”. De rol van deze laatste entiteit is het authentificeren van gebruikers en vailideren van rechten wanneer zij bepaalde data willen raadplegen. Ze staat ook in voor het bijhouden van licenties. Wanneer een consument data wil raadplegen (van de webserver of streaming media server) waarvoor hij nog geen licentie heeft, wordt een licentie aangemaakt en deze wordt bijgehouden op de “license server” (na het invullen van bijvoorbeeld een registratieformulier). De gebruiker verkrijgt de licentie waarna hij de digitale data kan gebruiken. Als hij wel al een licentie heeft en de data wil raadplegen, zal de webserver beroep doen op de “license server” en neemt een validatie van de rechten opgenomen in de licentie plaats: als de rechten nog geldig ( “valid”) zijn kan de gebruiker de data raadplegen. Wanneer de rechten niet meer geldig zijn, moet de gebruiker een nieuwe licentie aanvragen. Om de data te kunnen raadplegen, moet de consument beschikken over Windows Media Player dat Windows Media Rights Manager ondersteunt. Wanneer de consument bijvoorbeeld bepaalde content probeert af te spelen, zorgt Windows Media Rights Manager voor de authentificatie en validering van rechten. Er is een goede reden waarom de content enkel kan afgespeeld worden in een omgeving die Windows Media Rights Manager ondersteunt: wanneer men de data onderschept zal men het niet kunnen afspelen met een andere player. Hierdoor kan men het illegaal gebruik tegengaan: het is niet meer 38

interessant om de data te onderscheppen, omdat men toch moet beschikken over de juiste software om het af te spelen. Er kunnen verschillende soorten licenties gecre¨eerd worden; een “default” licentie kan bijvoorbeeld bevatten dat de data mag afgespeeld worden op een specifieke computer en dat het mag gekopieerd worden naar een portable device. Men kan eenvoudige tot zeer geavanceerde licenties defini¨eren. Licenties zijn wel niet doorgeefbaar. Wanneer een persoon een “packaged media file” doorzendt naar z’n vriend en daarbij ook z’n licentie, zal de licentie niet geldig zijn op de computer van die vriend, omdat iedere licentie “PC -gebonden” is. Op deze manier kan men verzekeren dat de data enkel door de gerechtmatigde gebruiker kan bekeken worden. Dit is een vorm van beveiliging om illegaal gebruik tegen te gaan (ik zal ze in het volgend hoofdstuk verder bespreken). Dus als men erin slaagt om op ´e´en of andere manier een gedecrypteerde versie van de content te bemachtigen, dan nog zal men de data niet kunnen afspelen met Windows Media Player, omdat de licentie een verwijzing naar de CPU bevat van de gerechtigde gebruiker. Ook de licentie aanpassen door het CPU-nummer te vervangen door een eigen CPU-nummer helpt niet: de licentie informatie zal immers niet overeenkomen met de informatie opgenomen in het “License Clearing House”. Licenties laten de producent toe om een aantal “business rules” m.b.t. het gebruik van data te defini¨eren: 1. Hoeveel keer kan een bestand afgespeeld worden? 2. Op welke device kan het bestand worden afgespeeld? 3. Mag de gebruiker backups maken van de digitale content? 4. Hoe lang mag de gebruiker de digitale content gebruiken (tijdsinterval)?

3.2.2

Windows RMS

Windows RMS of voluit “Windows Rights Management Services” [67] is een door Microsoft ontworpen systeem om digitale objecten te beschermen waarop intellectuele eigendomsrechten rusten, niet enkel voordat het bij de rechthebbende komt maar ook erna. Hiermee bedoelt men het volgende: men wil verhinderen dat de persoon die rechten heeft over een digitaal object, dit object of vertrouwelijke informatie (financi¨ele rapporten, bedrijfsresultaten, lonen,...) uit dit object zomaar verder kan verspreiden. RMS beperkt 39

de “verspreidingsmogelijkheden” van de gedecrypteerde content die in het bezit is van de rechthebbende. Windows RMS is eerder bedoeld voor een gesloten systeem (intranet) zoals de overheid, ziekenhuisinstellingen, het leger... Dit zijn systemen waar protectie van vertrouwelijke informatie zeer belangrijk is. Het kan evenwel ook in commerci¨ele omgevingen gebruikt worden, bijvoorbeeld binnen bedrijven, om interne informatie te beschermen. Wanneer men Windows RMS wil gebruiken, moeten alle deelsystemen binnen het systeem beschikken over “RMS-enabled software”. Alle computers in het systeem moeten uitgerust zijn met dergelijke software en bovendien moeten ze ook erkend zijn door een centrale RMS server (zie architectuur). Dit wijst nogmaals op het feit dat men in de wereld van DRM streeft naar standaardisatie en globalisatie. Windows RMS-functionaliteit is momenteel ge¨ımplementeerd in Office 2003. Wanneer twee personen bijvoorbeeld elk een legale versie van Office 2003 bezitten kan de ene persoon met Outlook een e-mail verzenden naar de andere persoon zodanig dat deze laatste de e-mail niet kan afdrukken. De verzender van de mail kan ook specifi¨eren dat de e-mail zich moet vernietigen na x aantal uur. In bedrijven kan men zo bepalen welke personen bepaalde informatie te zien krijgen en welke niet, doordat voor elke persoon andere rechten kunnen gedefinieerd worden op het gebruik van die informatie. Windows RMS gebruikt XrML voor z’n interne communicatie. Architectuur

Figuur 3.2: Windows Rights Managing Services: architectuur

1. Subsysteem A krijgt een “client licensor certificate”: dit gebeurt slechts ´e´enmalig om de machine te activeren binnen het systeem. 40

2. Subsysteem A maakt een bestand aan (bijvoorbeeld een Word document) en definieert er rechten op. De RMS-enabled applicatie cre¨eert een “publishing license” en encrypteert het bestand. 3. Subsysteem A verspreidt het bestand binnen het systeem. 4. Wanneer subsysteem B het bestand wil openen, zal z’n RMS-enabled applicatie een connectie leggen met de RMS server die subsysteem B gaat valideren (er wordt gechecked als het subsysteem gekend is en als hij opgenomen is in de “publish license” van de verzender). Tevens wordt een Use License gecre¨eerd, die de rechten bevat die gedefinieerd werden door de zender. 5. De applicatie opent het bestand en zorgt dat de rechten die gedefinieerd werden door subsysteem A (en beschreven staan in de “Use License” ) doorgevoerd worden. Uitleg Zoals eerder aangehaald is RMS vooral bedoeld voor een gesloten systeem. Alle subsystemen zijn gerelateerd aan een centrale RMS server, die instaat voor authentificatie en opstellen van licenties. Initieel moeten alle subsystemen geactiveerd worden. Op deze manier zijn alle partijen gekend en geauthentificeerd in de RMS server. Als een subsysteem dan een digitaal object wil verzenden naar een ander subsysteem, geeft hij de rechten op die deze andere partij mag uitoefenen. In de volgende stap zal de RMS server, na authentificatie van de zender, een “publisher license” geven aan deze zender. Deze “publisher license” bevat informatie over alle gerechtigde ontvangers van de data en wat hun rechten zijn. De RMS-enabled applicatie van de zender zal de content encrypteren. Nu kan de zender zijn data vrij verspreiden binnen het systeem . Wanneer een ontvanger deze data wil raadplegen, wordt eerst gekeken of deze ontvanger wel geauthentificeerd is (als hij gekend is in het systeem) en als hij opgenomen is in de publisher license van de zender. Hiertoe zal de RMS enabled software op de client een connectie leggen met de RMS server. Zijn de rechten nog geldig (bijvoorbeeld tijdslimiet) en is de gebruiker geauthentificeerd, dan zal de RMS software op de client de data decrypteren en kan de gebruiker ze raadplegen, weliswaar beperkt door de opgegeven rechten (zoals gedefinieerd in de aangemaakte “Use License”). De license server bestaat uit ´e´en of meerde fysische servers achter een virtuele URL. Aan elk van deze fysische servers is een databank gehecht (waar de informatie en authentificatie41

info wordt bijgehouden). De reden waarom men meerdere fysische servers voorziet is veiligheid: bij het uitvallen van een server kan men nog terugvallen op een andere. Windows RMS zorgt ervoor dat de data beschermd blijft, ook nadat het bij de rechthebbende terechtgekomen is. Evenwel is het zo dat men andere technieken kan uitvinden om de informatie door te spelen (bijvoorbeeld fotograferen van een computerscherm). Het gaat dan echter wel om analoog kopi¨eren en door de zwakkere kwaliteit zijn deze kopie¨en minder interessant.

3.2.3

Real Helix DRM

“Helix DRM” wordt onder andere gebruikt in de “Real” software [46]. Real One heeft ongeveer dezelfde functionaliteiten als Windows Media Player, hoewel het sterk gebonden is aan zijn eigen formaat (.rm files). Het systeem bestaat uit de volgende onderdelen: 1. Helix Packager: subsysteem die de digitale data gaat encrypteren (in een package stoppen). Het package bevat naast de ge¨encrypteerde data ook nog business rules m.b.t. het gebruik van het opgenomen digitaal object. Het package kan dan online verspreid worden (streaming, webservers). 2. Helix License Service: dit onderdeel is een aparte server die zich bezighoudt met het aanmaken en beheren van licenties en het authentificeren van gebruikers. Het bevat eveneens een audittrail zodat “tracking” van data1 mogelijk wordt. 3. Helix DRM Client: dit subsysteem zorgt ervoor dat men digitale data kan downloaden en streamen in een veilige omgeving. Het is een controle-orgaan dat communiceert met de license server om te kijken als gespecificeerde business rules (in de bijhorende licentie) al of niet geldig zijn. Bovenop deze component kan men applicaties bouwen zoals RealOne. 1

Met “tracking” van data bedoelt men het opvolgen van het gebruik van data.

42

3.2.4

Quicktime iTunes

Apple gebruikt DRM in z’n online music store, “iTunes” [45]. De gebruiker kan (mits betaling) op een legale wijze muziek downloaden en naargelang de aangekochte licentie kan hij eventueel ook de muziek branden op secundaire media. Ook hier wordt er gebruikt gemaakt van een eigen formaat, om illegaal gebruik oninteressant/onmogelijk te maken.

3.3

Algemene architectuur

Uit voorgaande besproken architecturen blijkt dat ze min of meer dezelfde opbouw hebben. Hier zal ik dan ook een algemene architectuur bespreken die deze opbouw reflecteert.

Figuur 3.3: Algemene DRM architectuur (Bron: Technology[14]

43

B. Rosenblatt.

DRM: Business and

Beschrijving 1. De producent beveiligt zijn data op de “content server”, door deze data in een “package” te gieten. Eventueel kan hij al voorgedefinieerde rechten toevoegen aan zijn content, bijvoorbeeld rechten die voor iedereen geldig zijn. Wanneer dit gebeurd is kan hij de data (in ge¨encrypteerde vorm) vrij verspreiden. Bij de data wordt ook nog metadata toegevoegd, die dient ter beschrijving van de content. Eventueel kan ook nog andere informatie zoals contactgegevens en een URL van de producent toegevoegd worden. 2. Wanneer de consument vanuit een applicatie de data wil raadplegen, moet hij eerst over een licentie beschikken. Deze licentie bevat een sleutel om deze data te gaan “unlocken” en specifieke rechten m.b.t. het gebruik van de data. De consument kan een licentie aanvragen m.b.v. de ingebouwde DRM controller in de client. 3. Als hij over die licentie beschikt, gaat de DRM controller na of de rechten nog niet verstreken zijn (door attributen uit het ge¨encrypteerde “license package” te gaan verifi¨eren). Wanneer de verificatie goed verloopt, kan hij met zijn applicatie de data raadplegen en wordt de licentie upgedate (rechten worden aangepast). 4. Als hij niet beschikt over een licentie, of wanneer de rechten opgenomen in de licentie verstreken zijn, zal de DRM controller een aanvraag doen aan de license server. Deze license server zal een nieuwe licentie genereren met de “DRM license generator”. 5. Deze zal een aantal attributen ter identificatie van de consument opnemen (en eventueel van zijn omgeving). Deze attributen dienen later als verificatie bij het updaten van de licentie. Daarna worden de rechten afgesproken tussen consument en producent. Dit alles kan gebeuren vanuit de applicatie op de client, bijvoorbeeld met een formulier dat moet ingevuld worden door de consument. 6. Wanneer de licentie is aangemaakt, voert de consument een financi¨ele transactie uit om z’n licentie aan te kopen of om een update van de licentie te bekomen. 7. De license server maakt de licentie aan (met de eerder gespecificeerde rechten en id’s). Ook wordt in de licentie een sleutel opgenomen die de client kan gebruiken om de data te gaan unlocken.

44

8. De licentie wordt naar de client gestuurd. Als de verificatie goed verloopt, kan de consument de data raadplegen, rekening houdend met de beperkingen zoals beschreven in de rechten. De communicatie tussen de client en server gebeurt d.m.v. een “rights message protocol”. Er wordt een gemeenschappelijke taal gebruikt zodanig dat beide partijen met elkaar kunnen communiceren. Deze taal wordt een REL genoemd (zie hoofdstuk 2). Ze wordt gebruikt om licenties aan te maken, data te beschrijven en rechten te defini¨eren op data.

Uitbreiding algemene architectuur

Figuur 3.4: Algemene DRM architectuur met copyright component (Bron: B. Rosenblatt. DRM: Business and Technology[14]

45

De producent bepaalt welke rechten op gebruik van data toepasbaar zijn. Hierdoor is het mogelijk dat de producent over een potentieel grote macht beschikt, waardoor de consument misschien rechten ontnomen wordt die wel mogen door de wet. Dit probleem, dat al aangehaald werd in het inleidend hoofdstuk, kan men architecturaal oplossen door de algemene architectuur uit te breiden met een “rights directory server”, die rechten specificeert die onder de wet geldig zijn. Deze component zorgt ervoor dat een consument rechten (beschreven door de wet) op gebruik van de data kan toevoegen aan de licentie, onafhankelijk van de producent. Hierdoor wordt de macht van de producent verminderd. Als een consument dan een licentie aanvraagt en bijkomende rechten wil specificeren, zal hij eerst in de rights directory server kijken naar de gepaste “right” en dan wordt een rights request gedaan aan de tweede licentie server. Als deze rechten goedgekeurd worden door deze server, zal deze server communiceren met de gewone producer server en zo worden de rechten dan toegevoegd. De licentie wordt dan via een omweg langs deze server geleverd aan de consument. Deze kan dan nog eens controleren als de toevoeging gebeurd is. Wanneer de consument een bijkomend recht specificeert dat nogal menselijk interpreteerbaar of disussieerbaar is (zoals Fair Use) kan het zijn dat de rights directory server geen uitsluitsel kan geven over het al of niet toelaten van dit recht aan de licentie. Op dat moment zendt deze licentie server een bericht naar de consument met de melding dat menselijke tussenkomst nodig is.

3.4

Verdere beschrijving van een DRM architectuur

In dit deeltje ga ik andere componenten / features die zich in een DRM architectuur bevinden bespreken. Modellering van entiteiten en data Wanneer men verschillende soorten entiteiten en digitale objecten in een systeem heeft, is er nood aan een uniform model dat orde schept in het systeem. Men moet dus een onderscheid maken tussen een aantal abstracte hoofdobjecten die dan ingevuld kunnen worden met meer concrete objecten. Op die manier kan men gemakkelijker bijhouden wie de huidige gebruikers van het systeem zijn, welke data er voorhanden is,... Een voorbeeld 46

van zo’n systeem vindt men ook terug bij RELs (zie hoofdstuk 2). Modellering van entiteiten INDECS (“Interoperability of data in e-commerce systems”) [30] is een systeem dat instaat voor de modellering van objecten binnen een DRM architectuur. Het “Core Entities Model” maakt een onderscheid tussen Users, Rights en Content. Een “User” kan iedere mogelijke user zijn (van producent tot consument), “Content” staat voor de verschillende soorten data en “Rights” zijn de rechten die gedefinieerd worden op die data. Modellering van digitale objecten IFLA of “International Federation of Library Associations” [27] is een systeem om data te modelleren. Men deelt het digitaal object op in verschillende lagen. Op die manier kan men bijvoorbeeld verschillende rechten defini¨eren tijdens de creatie van een digitaal object. Een boek is bijvoorbeeld de materialisatie van een idee. Voor het boek en het idee kan men dan verschillende rechten defini¨eren. Een ander voordeel van dit lagensysteem is dat men een object kan gaan opdelen in verschillende stukken, waaraan men dan verschillende soorten rechten relateert. Een voorbeeld hiervan is een website die verschillende documenten bevat. Men kan afhankelijk van het document het afdrukken van dit document al of niet toelaten. Identificatie van entiteiten / beschrijving van gebruikers en data Het is duidelijk dat identificatie noodzakelijk is in een globaal systeem. Dit is ook zo in de materi¨ele wereld (bijvoorbeeld ISBN-nummers [?] bij boeken, barcodes bij producten). Ook moeten entiteiten en data op een goede manier kunnen beschreven worden, zodat geen ambigu¨ıteit kan bestaan bij het defini¨eren van rechten. Hierna volgt een kort overzicht van bestaande systemen voor deze doeleinden. Ik ga ze verder niet behandelen. Identificatie van entiteiten 1. URI (Uniform Resource Identifier). [60] 2. DOI (Digital Object Identifier). [10] 3. ISTC (International Standard Textual Work Code). [29] 47

Beschrijving van data Voor data bestaan er verschillende soorten beschrijvingssystemen. 1. EDItEUR ONIX (beschrijving van boeken). [20] 2. IMS Learning Resource Meta-data Information Model (beschrijving i.v.m educatieve doeleinden). [26]

Beschrijving van gebruikers 1. VCARD (beschrijft personen en organisaties). [51] 2. MARC (beschrijft de rol die gebruikers hebben m.b.t. data). [34] Communicatie Opdat verschillende DRM systemen met elkaar zouden kunnen communiceren moeten ze over een gemeenschappelijke taal bezitten.

3.5

Conclusie

In de praktijk zijn er verschillende DRM architecturen. Sommige worden gebruikt voor commerci¨ele doeleinden (bijvoorbeeld Windows Media Player), anderen worden dan weer gebruikt voor niet-commerci¨ele doeleinden (zoals het beschermen van informatie binnen een bedrijf). Het is echter wel duidelijk dat deze systemen een aantal gemeenschappelijke kenmerken hebben, ze vertonen een algemene gemeenschappelijke architectuur. Ze proberen zoveel mogelijk aan standaardisatie te doen door de werking van het systeem te beperken tot eigen gedefinieerde formaten. De licenties worden van de data gescheiden voor twee redenen. Ten eerste kan men op die manier aan ´e´en digitaal object verschillende licenties toekennen en ten tweede laat deze scheiding toe om meerdere businessmodellen te defini¨eren op dezelfde data. Het “copyright” probleem kan architecturaal opgelost worden door een bijkomende server te voorzien die aan de hand van een externe “rights data server” toegevoegde 48

rechten valideert. Deze rights data server bevat rechten op gebruik van data die volgens de wet beschreven zijn. Hierdoor zal de macht van de producent verminderen. Een DRM architectuur moet ook nog een aantal andere subsystemen hebben zoals modellering, beschrijving en identificatie van entiteiten, alsook een vorm van communicatie. Al deze componenten samen verhogen de uiteindelijke interoperabiliteit tussen verschillende DRM architecturen.

49

Hoofdstuk 4 DRM en beveiliging 4.1

Inleiding

De “perimeter based” beveiligingsmethoden (firewalls1 , ACL2 ) die in de eerste generatie van DRM gebruikt werden waren niet veilig. Eens men door de firewall kon geraken of de inloggegevens van de ACL kon manipuleren, had men toegang tot het systeem en ook tot de niet beveiligde data. In de tweede generatie DRM heeft men een aantal beveiligingstechnieken ingeleid die de beveiliging van data moeten verbeteren. Een goed DRM systeem bestaat op gebied van beveiliging uit 2 hoofdaspecten: kopiepreventie en kopiedetectie. Kopiepreventie slaat op het preventief optreden om illegaal gebruik van data tegen te gaan. Kopiedetectie slaat op het detecteren van illegale data. In dit hoofdstuk worden eerst een aantal technieken van beide domeinen besproken. In een laatste deel ga ik dan enkele systemen uit de praktijk toelichten. Ook ga ik in op enkele gevallen van inbraak in DRM systemen. Deze systemen maken gebruik van verschillende beveiligingstechnieken. Sommige van de aangehaalde technieken zijn al eens aan bod gekomen in hoofdstuk 3, omdat beveiliging en architecturen nauw met elkaar samenhangen. 1

een firewall is een bescherming van een systeem door hard- of software. Ze verleent de toegang tot bepaalde andere systemen afhankelijk van hun IP-adres. Tevens kunnen ook bepaalde poorten geblokkeerd worden. 2 Een lijst met gegevens op het gebied van beveiliging en beheer. Een ACL, voluit Access Control List wordt in diverse toepassingen gebruikt zoals besturingsssystemen en (netwerkgerelateerde) software. ACL’s bevatten vaak inloggegevens (accounts) voor de betreffende gebruikers die toegang tot een systeem of applicatie hebben.

50

Een overzicht: Kopiepreventie 1. Software: encryptie. 2. Software: gebruik van special software browser. 3. Hardware: gebruik van hardwarechip(s). 4. Hardware: decryptie in hardware. 5. Hardware: gebruik van hardware als bijkomend identificatiemiddel. 6. Combinatie hard- en software. Kopiedetectie 1. Watermerken.

4.2

Kopiepreventie

Kopiepreventie gebeurt voornamelijk door het encrypteren van de data. Sommige technieken gebruiken software, andere gebruiken enkel hardware en er zijn ook nog enkele technieken die software en hardware combineren.

4.2.1

Software

Encryptie Dit is de eenvoudigste en meteen ook de meest onveilige manier om data te beschermen. Er zijn verschillende beveiligingsalgoritmen beschikbaar om data te encrypteren: DES, IDEA, RSA, Blowfish, Crab, Feal, Khafre, ... 3 De werking van deze algoritmen is meestal gekend (of gemakkelijk te achterhalen) waardoor ervaren cryptografen de data gemakkelijk kunnen decrypteren. 3

Zie cursus “Internet toepassingen: architectuur en technologie” voor verdere informatie.

51

Gebruik van “special software browser” [53] Deze vorm van beveiliging is de meest gebruikte binnen DRM. Er wordt gebruik gemaakt van een speciaal ontwikkelde browser die de data enkel zal “tonen” aan de consument. Wanneer de ge¨encrypteerde data in deze browser binnenkomt, zal deze browser de data gaan decrypteren en het resultaat tonen aan de gebruiker, zonder ook maar ´e´en bit gedecrypteerde data na te laten op de computer van de gebruiker. De data wordt volledig binnen de browser gedecrypteerd en de gedecrypteerde informatie wordt softwarematig in de browser gehouden. Eventueel kan gebruik gemaakt worden van hardware (zie verder). De gedecrypteerde data blijft dan in de hardware en komt zelfs niet in de softwarematige browser. Het gebruik van een special software browser is veilig, hoewel het ook mogelijk is de werking van de browser te ontleden, (door disassembleren van de software) zodanig dat men toch nog aan de gedecrypteerde data kan.

4.2.2

Hardware

Gebruik van hardwarechip(s) Dit is de zwaarste vorm van gebruik van hardware: op het moederbord soldeert men een component die DRM implementeert. Eventueel kan men de chip integreren in de hoofdprocessor. Deze chip controleert alles: zijn de programma’s op de pc legaal? Welke bestandsformaten worden er uitgewisseld tussen platformen en zijn deze bestanden legaal? Om dit te verwezenlijken zal men samenwerken met het besturingssysteem en externe servers, die regels tot gebruik van bepaalde programma’s en bestanden kunnen invoeren. Deze beveiligingstechniek heeft een sterk globaliserend karakter; wil men een goede werking dan moet het aanwezig zijn in alle computers. Deze vorm van beveiliging is zeer moeilijk te kraken: men zou eventueel ongecodeerde data uit de bus tussen de CPU en de “DRM-chip” kunnen gaan uitlezen, maar dit vraagt veel tijd en is niet zo evident. Wanneer men de chip integreert in de hoofdprocessor, zal het kraken nog moeilijker worden: dit is weggelegd voor zeer professionele technici die het met veel geld, tijd en moeite kunnen doen.

52

Decryptie in hardware Een alternatief voor de softwaretechnieken is de decryptie uitvoeren in hardware. Wanneer data in een systeem binnenkomt (bijvoorbeeld op een consument zijn pc) zal hardware (bijvoorbeeld het beeldscherm) de data decrypteren en het gedecrypteerde bestand tonen aan de consument. Het gedecrypteerde bestand blijft in de hardware van het beeldscherm zelf. Het is dus onmogelijk voor de consument om de data verder te gaan verspreiden. Deze manier van kopiepreventie is zeer effici¨ent. Jammergenoeg is ze economisch gezien zeer moeilijk (quasi onmogelijk) in te voeren. Wanneer men deze techniek zou willen toepassen, zouden alle soorten beeldschermen deze techniek moeten ondersteunen, er zou dus nood zijn aan een standaard beeldscherm. Door de huidige concurrentie en diversiteit in de industrie is dit natuurlijk een onhaalbare kaart. Decryptie in hardware kan ook ruimer gezien worden, het moet niet beperkt worden tot ´e´en device. Intel en IBM hebben bijvoorbeeld een voorstel om DRM in te bakken in hun harde schijven en in het algemeen in besturingssystemen. Op die manier zou het mogelijk zijn om een bestand als “copyrighted” te markeren, waardoor het kopi¨eren van dit bestand onmogelijk zou worden. Dit voorstel staat bekend als “CPRM” (Content Protection for Recordable Media) [7]. Opnieuw is het zo dat dit voorstel economisch gezien zeer moeilijk wordt om waar te maken, om dezelfde reden zojuist aangehaald. Hoewel de consument niet aan de gedecrypteerde data kan, is het nog altijd mogelijk dat hij analoge kopie¨en kan maken van de data. Hij kan bijvoorbeeld het geluid opnemen met een geluidsrecorder, of foto’s nemen van een beeldscherm, ... Dit probleem is onoverkomelijk en zal altijd blijven bestaan. Wel is het zo dat deze kopie¨en veel slechter zijn dan de gewone digitale kopie. Hoewel een computerpiraat deze data kan verspreiden, zal hij er minder profijt aan hebben door de slechtere kwaliteit. Hierdoor zal het niet meer interessant zijn om illegale data te verspreiden. Deze techniek is dus een goeie stap in het tegengaan van piraterij. Gebruik van hardware als bijkomend identificatiemiddel Men kan ervoor zorgen dat data gebonden wordt aan een bepaalde omgeving (computer). Een film kan bijvoorbeeld enkel maar afspeelbaar zijn op ´e´en PC. Hiervoor doet men beroep op hardwarecomponenten als identificatiemiddel. Wanneer men digitale data op een PC probeert te raadplegen, zal de hardwarecomponent vergeleken worden met de 53

beschrijving van de hardwarecomponent in de bijhorende licentie. Men kan bijvoorbeeld kijken naar het CPU nummer, harde schijven gaan identificeren, ... Op die manier kan men de illegale spreiding van data tegengaan: als iemand de licentie doorgeeft aan een tweede persoon zal deze laatste de data niet kunnen raadplegen. Om de data te kunnen raadplegen moet men beschikken over speciale software die de licenties controleert. Deze software zal bij de tweede persoon detecteren dat de omgeving verschillend is van de omgeving die in de doorgegeven licentie is opgenomen.

4.2.3

Combinatie hard- en software

In vele systemen worden hierboven beschreven technieken met elkaar gecombineerd, wat ook uit de praktijkvoorbeelden zal blijken.

4.3

Kopiedetectie

Kopiedetectie gebeurt door het gebruik van watermerken. Op die manier kan men zien als bepaalde data illegaal is of als er eventueel wijzigingen zijn gebeurd aan de data door derden. Ook kan men bijvoorbeeld “tracking” informatie opnemen in een watermerk om de distributie van data beter te kunnen controleren. Kopiedetectie is bijvoorbeeld zeer interessant op het gebied van REL. Een buitenstaander zou gemakkellijk de rechten in het document kunnen vervangen. Watermerken worden ook gebruikt op een ander gebied, namelijk om illegaal kopi¨eren tegen te gaan.

4.3.1

Watermerken [16]

In dit stukje ga ik kort aanhalen wat watermerken zijn, welke soorten watermerken er zijn en waarvoor ze kunnen gebruikt worden. Watermarkering maakt deel uit van de “steganografie”4 . Het bestaat uit het toevoegen van onzichtbare data aan zichtbare data. Een voorbeeld hiervan is het toevoegen van copyright informatie die onzichtbaar is aan een afbeelding. Watermarkering is geen vorm 4

Een technologie om informatie in afbeeldingen, teksten of geluidsfragmenten te verstoppen (“information hiding technique”). Het is een vorm van geheimschrijven. De naam is afkomstig uit het Grieks. stegan´ os = bedekt, verborgen; grafein = schrijven

54

van encryptie. Een watermerk gaat de data wel wijzigen, maar laat deze data zelf in een “heldere” vorm. De data blijft dus perfect leesbaar (ongeacht de aanwezigheid van het watermerk). Er zijn ook watermerken die ervoor kunnen zorgen dat de data onzichtbaar wordt. Er zijn 3 soorten van watermerken: 1. Forensic watermarks: Bij deze vorm van watermarkering blijft de data zichtbaar (en dus perfect kopieerbaar). Het toegevoegde watermerk bevat “tracking informatie”. 2. Denial watermarks: deze watermerken worden gebruikt om kopi¨eren tegen te gaan. Wanneer data een watermerk niet bevat, wijst dit erop dat de data een kopie is; deze kopie wordt dan ook genegeerd (“denial”). 3. Multi phase watermarks: dit is de modernste manier van watermarkering. Er treedt een verandering op in de data: in de initi¨ele toestand is de data ge¨encodeerd. Wanneer de consument dan een licentie verkrijgt op de data wordt aan de gedecodeerde data een watermark toegevoegd ter identificatie van de consument. Op dat moment bevindt de data zich in de tweede fase. Het opnemen van identificatiegegevens van een gebruiker aan data wordt ook nog “fingerprinting” genoemd.

4.4

Beveiliging in de praktijk

In dit deel ga ik enkele systemen bespreken die in de praktijk gebruikt worden of gepland zijn om in de praktijk gebruikt te worden.

4.4.1

Adobe Merchant en Adobe Web Pay [2]

Deze twee softwaremodules worden gebruikt om DRM te implementeren in Adobe Acrobat Reader[1]. Adobe Acrobat Reader is software om o.a. online e-books te raadplegen. Het systeem combineert zowel technieken op hard- als softwareniveau. Meer specifiek wordt er gebruik gemaakt van volgende technieken: 1. software encryptie 55

2. gebruik van een “special software browser” 3. identificatie m.b.v. hardware Werking Nadat de producent zijn document (bijvoorbeeld een e-book) heeft aangemaakt (in het kader van Adobe Acrobat Reader in .pdf formaat), zal het document ge¨encrypteerd worden m.b.v. Adobe Merchant. Voor de encryptie gebruikt men RSA. Hierna kan de producent de “locked” data online zetten zodat het door consumenten kan geraadpleegd worden. De locked data bevat ook een URL die verwijst naar de producent. Wanneer de consument het boek online wil raadplegen, wordt een aantal “identifiers” opgehaald om de consument te identificeren. De “User ID” houdt informatie bij over de consument (naam, adres, telefoonnummer,...). Naast de User ID zal het systeem ook nog enkele hardwarematige ID’s ophalen: CPU ID (wat is het CPU-nr van de consument?), Removable Disk ID (het document mag enkel opgeslaan worden op de disk van de gebruiker), Network Disk ID (het document mag enkel opgeslaan worden op een disk die toegankelijk is voor een aantal gebruikers). Al deze gegevens worden opgeslaan in een databank (op de server). Na een financi¨ele tussenkomst wordt het e-book (in ge¨encrypteerde vorm) en ook een voucher gedownload naar de pc van de gebruiker. De gebruiker kan het document enkel bekijken met Adobe Acrobat Reader die uitgerust is met Adobe Web Pay. Deze laatste zal immers zorgen dat het document kan worden gedecrypteerd. De voucher zorgt ervoor dat het e-book enkel in de gebruikersomgeving van de consument kan worden geraadpleegd, en nergens anders. Het is een door de auteur digitaal gesigneerd bestand dat volgende informatie bevat: een document ID, rechten van de consument, een beschrijving van de omgeving van de gebruiker en ook nog de hardware ID’s. Wanneer de consument dan vanop z’n computer het document wil openen, zal Adobe Web Pay informatie van de consument ophalen. Deze informatie wordt vergeleken met de informatie die in de voucher is opgeslaan. (Bijvoorbeeld, vergelijken hardware-id consument met de in de voucher opgenomen hardware-id). Om deze informatie te checken wordt gebruik gemaakt van speciale omgevingsexpressies die eigen zijn aan Adobe. Wanneer de verificatie succesvol is, zal Web Pay het document decrypteren en de inhoud tonen aan de gebruiker, zonder ook maar n bit gedecrypteerde informatie achter 56

te laten op de PC van de gebruiker (er wordt wel informatie achtergelaten op de pc van de gebruiker, maar de effectieve informatie is niet toegankelijk voor de gebruiker, hij kan enkel de informatie raadplegen m.b.v. de browser). De gedecrypteerde data blijft in de browser zelf en niet daarbuiten. Na raadpleging van de informatie wordt de gedecrypteerde data (binnen de browser) terug gewist. Het systeem is redelijk veilig, men kan enkel aan de gedecrypteerde informatie komen door de browser te gaan ontleden (d.m.v. disassembleren).

4.4.2

Microsoft NGSCB

Dit praktijkvoorbeeld illustreert vooral het gebruik van een hardwarechip, hoewel het ook nog andere technieken van DRM implementeert (gebruik van speciale software, watermerken). Microsoft NGSCB5 [35] is een project van de TCG [59] (Trusted Computing Group). De TCG is een alliantie tussen Microsoft, Intel, IBM, HP en AMD die een standaard voor een “veiligere” PC wil bevorderen. Het project is ook nog bekend onder andere namen. Origineel heette het “trusted computing”, andere namen zijn TCPA6 (vroegere benaming voor TCG) en Palladium. Dit project is zeer controversieel: het hoofddoel van het project is een globale controle in te voeren op de computer van de consument, niet enkel met het subdoel om een veiliger systeem aan te bieden aan de gebruiker, maar vooral om de winsten van de industrie te vergroten. Het stuit op zeer veel negatieve kritiek, vooral om z’n globaliserend en monopoliserend karakter. Microsoft NGSCB zorgt ervoor dat de consument niet kan knoeien met de programma’s die op z’n systeem draaien. Het zorgt ook voor een sterke communicatie tussen deze programma’s en de makers ervan (door gebruik van servers: zie verder). Op die manier hebben de makers meer controle over hun programma’s en kunnen ze ook het gebruik van deze programma’s beter controleren (ze kunnen rechten afdwingen op het gebruik van hun programma, waardoor ze grotere winsten kunnen boeken). 5 6

Microsoft Next-Generation Secure Computing Base. Trusted Computing Platform Alliance.

57

NGSCB doet ook aan “traitor tracing”. Door controle vanaf externe servers kan men illegale kopie¨en van data gaan detecteren (m.b.v watermerken) en gaan verwijderen. Het zal ook zorgen dat ongelicenseerde software moeilijker wordt om te gebruiken. Men streeft ernaar om een standaard in te voeren, nl “legale TC programma’s”, zodat het gebruik van illegale software (of software niet erkend door TC) moeilijker en oninteressanter wordt. Deze TC programma’s zouden beter met elkaar kunnen samenwerken, er zouden bestandsformaten gebruikt worden die enkel door TC programma’s kunnen gelezen worden waardoor op termijn niet-TC programma’s onbruikbaar zouden worden (als iedereen TC programma’s gebruikt zullen de niet-TC programma’s weinig interoperabiliteit vertonen met TC programma’s). De niet-TC programma’s zullen dus moeilijker bruikbaar zijn, waardoor ze uiteindelijk in een isolement terechtkomen. De consument zal dan verplicht worden over te gaan op de erkende TC-software. Werking van NGSCB [58] TC bestond aanvankelijk uit ´e´en chip, de “Fritz”7 chip genaamd, die op het moederbord gesoldeerd werd. De huidige versie (Microsoft NGSCB) bestaat uit vijf componenten: de chip, een “gesluierd geheugen” systeem in de processor, een veiligheidskernel in het besturingssysteem (de Nexus), een soortgelijke kernel in elke TC-applicatie (NCA) en een ondersteunende infrastructuur van online servers, opgezet door soft- en hardwareleveranciers, om alles aan elkaar te knopen. De eerste versie van TC zorgde ervoor dat Fritz aan het hoofd van het opstartproces van de PC stond, zodat de PC in een gecontroleerde staat terechtkwam, met gelicenseerde hard- en software. Wanneer de PC illegale soft- of hardwarecomponenten bevatte, startte de PC gewoonweg niet op. Omdat de eerste versie van TC te strikt was, ging men in een tweede versie (Microsoft NGSCB) de chip als een passief controlerende component zien. Wanneer de computer opstart, gaat de chip de opstartstatus van de machine opslaan als hashwaarde. Deze waarde wordt berekend a.d.h.v. de in de machine aanwezige hard- en softwarecomponenten. Wanneer de hashwaarde geldig is, wordt de machine opgestart en zal de chip een cryptografische sleutel aan het besturingssysteem geven, die het in staat stelt om al de 7

Genoemd naar Fritz Hollings, een senator in South Carolina, die in het Amerikaans congres met volle macht probeerde om TC een verplicht onderdeel te maken van de consumentenelektronica, Hollings’ wetvoorstel haalde het echter niet

58

TC-programma’s en data te gaan unlocken. Op dat moment is de PC volkomen legaal en erkend door het Microsoft systeem. Wanneer de hashwaarde echter niet klopt, wordt de PC in gewone modus opgestart en kan men geen gebruik maken van de TC-programma’s. Men kan evenwel nog altijd gebruik maken van niet-TC programma’s, daar waar dat in de eerste versie niet mogelijk was. Dit kan als een pluspunt gezien worden, maar door de standaardisatie naar TC-programma’s en TC-data zal blijken dat deze functie oninteressant is: de niet-TC programma’s zullen onbruikbaar worden. Om bij het opstarten de hashwaarde te kunnen berekenen, maakt de chip gebruik van de Nexus, dit is een veiligheidskernel in het besturingssysteem. Deze “Nexus” zal checken of alle applicaties legaal zijn (m.b.v. de NCA, de veiligheidscomponenten van de applicaties) en zal kijken als alle hardwarecomponenten TC-goedgekeurd zijn. Ook gebruikt de Nexus het principe van “gesluierd geheugen” om te voorkomen dat het ene TC-programma data van een ander TC-programma kan lezen of schrijven. Wanneer de machine in een “goede staat” is, zal de Fritz chip dit meedelen aan derden. Door middel van een authentificatieprotocol kunnen commerci¨ele instellingen vanaf hun server gecodeerde data zenden naar de legale, gekende omgeving. Bij deze gecodeerde data zit een sleutel die Fritz zal gebruiken om de data te decoderen. Het is duidelijk dat Microsoft NGSCB probeert niet-TC software te bannen. Wanneer men zijn eigen PC opstart in “niet-TC” mode, zal Fritz je niet de sleutels geven die je nodig hebt om toegang tot bestanden te krijgen, gebruik te maken van TC-software,... Wanneer men dan nog eens deze TC-programma’s aantrekkelijk gaat maken zodat ze door de meeste mensen gebruikt worden, of meer winstgevend gemaakt worden voor de leveranciers, zal je verplicht zijn de TC-applicaties te gaan gebruiken. Men zal dus moeten betalen om mee te kunnen draaien in de informaticawereld.

4.5

Beveiligingsinbraken [12]

In dit stukje ga ik enkele voorbeelden aanhalen van inbraken in DRM systemen. Deze voorbeelden tonen aan dat de beschreven DRM technieken en in het algemeen DRM nog in een vroeg stadium zitten en gemakkelijk ten prooi kunnen vallen van inbraken.

59

4.5.1

Dimitry Sklyarov en Adobe eBook kopieprotectie

In juni 2001 heeft Dimitry Sklyarov, een russisch programmeur, een programma geschreven dat de DRM technologie van Adobe kon kraken. In juli werd deze man gearresteerd omdat hij de DMCA (zie inleidend hoofstuk) niet had nageleefd. Kort daarna heeft Sklyarov ook nog een verhandeling gepubliceerd die informatie bevatte omtrent het kraken van de Adobe ROT-13 kopieprotectie. De man moest een aantal weken in de gevangenis vertoeven en werd vrijgelaten met een borgsom van 50.000 dollar.

4.5.2

Ed Felten: een academische inbraak in DRM Systemen

In april 2001 verkondigde een groep van onderzoekers onder leiding van professor Ed Felten van de Princeton Universiteit, dat ze het DRM systeem ontwikkeld door SDMI8 [55] konden kraken. Ed Felten was van plan z’n verhandeling met de relevante informatie te publiceren, maar hij werd door SDMI en de RIAA9 [48] aangeklaagd voor het schenden van de DMCA. Felten besloot dan om z’n werk niet te publiceren. Omdat Felten had aangekondigd dat het systeem te kraken was, en heel de bedoeling eigenlijk academisch getint was, werden de aanklachten tegen hem en z’n groep ingetrokken.

4.5.3

Stephen King en “Riding the Bullet”

Een aantal jaar terug besloot Stephen King (een welbekend horrorauteur) zijn recentste boek “Riding the Bullet” online te plaatsen. Lezers konden, mits betaling van een kleine som, het boek online raadplegen. De lezers hadden enkel “read-only use rights”: ze konden het boek niet uitdrukken, opslaan, bewerken of verder distribueren. Om het boek te kunnen lezen, moest men GlassBook Software gebruiken. Deze software (een vorm van een “speciale software browser”) zorgde ervoor dat de lezers enkel read-only rights hadden door een encryptie in te voeren in het systeem. Deze encryptie werd echter snel achterhaald, en na een korte tijd was het boek ergens anders gratis online beschikbaar. Omdat het boek copyrighted was en het kraken van het systeem illegaal is, stapte King naar het gerecht. Uiteindelijk kon King de opgelopen financi¨ele schade beperken tot 150.000 8 9

Secure Digital Media Initiative. Recording Industry Artists of America.

60

dollar. Hieuit blijkt nog eens de rol van de wet: zonder de wet zou King nog een grotere financi¨ele schade opgelopen hebben...

4.6

Conclusie

Uit de besproken beveiligingstechnieken blijkt dat vooral hardware een oplossing kan bieden om de intellectuele eigendomsrechten op digitale data te beschermen, en om dus een grotere winst te boeken voor de industrie. Het doorvoeren van hardwaretechnieken is economisch zeer moeilijk, omdat er nood is aan een standaardisatie binnen de hardwaresector (alle hardwareproducenten moeten de hardwaretechnieken ondersteunen). Hoewel bovenstaande beveiligingstechnieken de piraterij enigszins kunnen tegengaan, blijven toch nog een aantal problemen onoverkomelijk. Ten eerste blijft het analoog kopi¨eren van data nog altijd mogelijk. Dit probleem is niet zo ernstig aangezien analoge kopies van mindere kwaliteit zijn dan digitale kopies. Het onmogelijk maken van exacte digitale kopies zou de piraterij sterk kunnen remmen. Ten tweede zal het altijd mogelijk blijven om in de “supply chain” van producent naar consument data te gaan onderscheppen, en hoe moeilijk dit ook mag zijn, deze data te gaan decrypteren. Het Internet is nu eenmaal van nature uit een onveilig medium. Uit de beveiligingsinbraken blijkt dat de technieken niet altijd even veilig zijn en dat er zeker nog veel onderzoek moet gedaan worden om een veilig systeem te kunnen ontwikkelen.

61

Deel II Praktisch gedeelte

62

Hoofdstuk 5 Onderzoek naar MPEG-21 referentiesoftware 5.1

Inleiding

In het kader van de ontwikkeling van de MPEG-21 REL parser heb ik eerst gerelateerde referentiesoftware onderzocht. Deze referentiesoftware kunnen bestempeld worden als “drafts” die mits goedkeuring van de MPEG-21 [37] groepering, een grote rol kunnen spelen in de verdere ontwikkeling van dit framework. Bij m’n onderzoek heb ik nagegaan als de software wel degelijk werkt, wat het doel is en wat het resultaat is. Deze software is er vooral om aan te tonen dat bepaalde functionaliteiten mogelijk zijn, ze leggen de basis voor verdere ontwikkeling van interessante tools. Sommige tools trachten ook verschillende delen van MPEG-21 te combineren. De software die ik heb onderzocht heeft naast MPEG-21 REL, ook betrekking op MPEG-21 RDD en MPEG-21 DID. Hieronder een overzicht: MPEG-21 REL referentiesoftware 1. License Schema Checker 2. License Validation Rules Checker 3. License Creator 4. License Interpreter 63

MPEG RDD referentiesoftware 1. RDD Browser Interface 2. RDD Database Query

Referentiesoftware als combinatie van MPEG-21 REL en andere delen van MPEG-21

1. REL License interpretation die gebruikt maakt van RDD terminologie

5.2 5.2.1

MPEG-21 REL referentiesoftware License Schema Checker

Figuur 5.1: MPEG-21 REL: License schema checker

Beschrijving Nagaan of een REL-document syntactisch voldoet aan de in het document opgenomen schema’s. Er wordt gebruikt gemaakt van de Xerces Parser. Deze tool kan gebruikt worden in andere referentiesoftware als “hulptool”.

64

Input Een lijst van REL documenten of een directory die REL documenten bevat. Output Een melding als het document al of niet syntactisch “valid” is en in geval van “not valid” de redenen waarom dit zo is, steunend op de schema’s. Enkele voorbeelden van mogelijke redenen waarom het document niet geldig is: 1. Datatype error: In element “dsig:Modulus”: Value “KtdTobzA==” is not encoded in Base64. (fout tegen schema m.b.t. Digital Signature) 2. The content of element type “r:grant” must match “((forAll*,delegationControl?, principal?,right,resource?,condition?)—encryptedGrant)”. (Fout tegen Core schema). Werking Goed.

5.2.2

License Validation Rules Checker

Figuur 5.2: MPEG-21 REL: License validation rules checker

65

Beschrijving Deze tool gaat na of een syntactisch valid REL document (een document dat dus voldoet aan de schema’s opgenomen in het document) voldoet aan de door MPEG-21 gespecificeerde “validation rules”. Wanneer dit zo is, zegt men dat het REL document “REL syntactisch conformant” is. Een REL document moet dus naast syntactisch in orde te zijn, ook voldoen aan de door MPEG-21 opgelegde validation rules. De validation rules leggen een semantiek op aan REL documenten. Een voorbeeld van een validation rule is: “a r:LicensePart shall not have both the r:licensePartId attribute and the r:licensePartIdRef attribute.”

Soms kan het nodig zijn dat de licentie eerst moet getransformeerd worden, dit is het geval wanneer de licentie “r:licensePart” elementen bevat die “licensePartId” en “licensePartIdRef” attributen hebben. Men doet deze transformatie zodanig dat het toepassen van de validation rules op het document gemakkelijker kan verlopen. Net zoals de Schema Checker kan deze tool ingebed worden in grotere toepassingen (zie verder). Input Een syntactisch valid REL document (dat dus voldoet aan alle opgenomen schema’s). Output Een melding als het document al of niet REL syntactisch conformant is. Wanneer het document niet REL syntactisch conformant, wordt een boodschap uitgeschreven. Een voorbeeld van een slechte output: “Invalid license. Element with attribute licensePartId is ancestor of the element with attribute licensePartIdRef with the same value x.” Werking Goed. 66

5.2.3

License Creator

Figuur 5.3: MPEG-21 REL: License creator

Beschrijving Deze module biedt een gemakkelijke manier om MPEG-21 REL licenties aan te maken. De gebruiker kan een licentie aanmaken door simpelweg informatie in te vullen in een formulier, die zich op een webpagina bevindt. De gebruiker kan intikken wie de principal is, wat de rights en conditions zijn en wat de resource is waarover de gespecificeerde rechten moeten gedefinieerd worden. Deze informatie zal gebruikt worden om op de server een licentie te genereren. Om de informatie om te zetten in een MPEG-21 REL document gebruikt men een DOM Parser. Wanneer de XML gegenereerd is, wordt m.b.v. de Schema Checker nagegaan als het aangemaakte document geldig is. Wanneer dit zo is wordt het document teruggestuurd naar de gebruiker. Deze referentiesoftware heeft dezelfde functie als RightsExpress (ContentGuard).

67

Input Informatie verschaft door de gebruiker. Deze informatie moet minstens genoeg zijn om een minimale basislicentie te cre¨eren. Output Een schema valid REL document. Werking Goed. De software is wel beperkt qua mogelijkheden (er zijn bvb. slechts 4 mogelijke condities specificeerbaar). Kan nogal traag zijn naarmate de mogelijkheden groter worden door het gebruik van een DOM parser.

5.2.4

License Interpreter

Figuur 5.4: MPEG-21 REL: License interpreter

68

Beschrijving Deze module is een primitieve implementatie van een systeem die REL documenten kan interpreteren. Het systeem krijgt 2 inputs: Het eerste inputgegeven is een REL document dat een licentie voorstelt. Als tweede input is er ook nog een bestand dat informatie bevat over de rechten die gedefinieerd zijn in de licentie. Deze informatie stelt de huidige toestand voor van de condities (bijvoorbeeld: een boek is al 5 keer bekeken). Deze huidige waarden worden vergeleken met de in de licentie gespecificeerde waarden. Wanneer na vergelijking aan allle condities voldaan is, zal de license interpreter als resultaat “authorized” teruggeven: de gebruiker mag de data raadplegen. Het systeem is onderverdeeld in 2 hoofdmodules, de REL Parser Module en de Condition Evaluator. De eerstgenoemde bevat een module om de geldigheid van het REL document (syntactisch en semantisch) te gaan checken, een module om de licentie eventueel te transformeren (om gemakkelijker te kunnen valideren) en een module om de waarden uit de conditions van het REL document te halen. Deze module maakt o.a. gebruik van de Xerces Parser (checking) en XQuery (om de waarden van de conditions op te halen). De Condition Evaluator zal dan kijken als de conditions nog altijd geldig zijn of niet. Wanneer een gebruiker een document (bvb. een e-book) wil raadplegen zal het volgende plaatsvinden: 1. checken of het REL document syntactisch in orde is; 2. eventueel de licentie transformeren indien nodig; 3. checken of het REL document syntactisch conformant (semantisch) in orde is (d.i. aan de validation rules voldoet); 4. een query uitvoeren die de geldigheid van de gebruiker nagaat (authentificatie); 5. wanneer dit in orde is, worden de waarden van de condition-tags opgehaald en wordt een condition bestand gegenereerd; 6. dit condition bestand wordt gebruikt om in de tweede module te checken als de conditions geldig zijn; 7. wanneer de conditions geldig zijn, kan de gebruiker verder het e-book raadplegen, anders niet (user authorized/not authorized).

69

Input Een REL document (licentie) en een User File (gegevens over de gebruiker, wordt gebruikt voor authentificatie). Output Een melding als de condities voldaan zijn of niet (user authorized/not authorized). Eventueel kan bij fouten (niet geldige syntax, niet voldaan aan validation rules) een log bestand gegenereerd worden. Werking Goed. Wel beperkt: er kunnen maar twee condities op geldigheid getest worden nl. “ExcessLimit” en “ValidationInterval”.

5.3 5.3.1

MPEG RDD referentiesoftware RDD Browser Interface

Beschrijving Kan gebruikt worden om de definitie van een term en z’n bijhorende “geneaology” op te vragen uit de MPEG RDD. De “geneaology” is het verband van deze term met andere termen in de RDD. De client kan in een web-interface een term aanklikken waarna de informatie tevoorschijn komt. De client kan dus browsen doorheen de RDD. Input Een RDD-term. Output Defintie + “geneaology” van die term. 70

Werking Goed.

5.3.2

RDD Database Query

Beschrijving Deze module heeft ongeveer dezelfde werking als de voorgaande: een gebruiker tikt een term in waarna hij de geneaology als vector krijgt en hij krijgt ook een “IsTypeOf” hi¨erarchie te zien (boomstructuur). Input Een RDD term. Output “Geneaology” van de term en “IsTypeOf” hi¨erarchie. Werking Goed.

5.4

Referentiesoftware als combinatie van MPEG-21 delen

Ter vervollediging vermeld ik hier nog: 1. REL License interpretation die gebruik maakt van RDD terminologie. Deze software heb ik niet kunnen testen omdat ze nog niet beschikbaar is.

71

5.5

Conclusie

Op het gebied van MPEG-21 is er reeds een groot aanbod aan referentiesoftware aanwezig. Deze referentiesoftware heeft betrekking op REL en RDD. De software werkt over het algemeen goed, hoewel ze in vele gevallen nogal beperkt is. Ze zijn bedoeld als onderzoek in de hoop dat ze een steentje kunnen bijdragen aan de verdere ontwikkeling van MPEG-21.

72

Hoofdstuk 6 Ontwikkeling van een MPEG-21 REL parser en toepassing 6.1

Inleiding

Dit hoofdstuk beschrijft het belangrijkste element van het praktische gedeelte, namelijk de ontwikkeling van een MPEG-21 REL parser. In het tweede deel van dit hoofdstuk wordt een toepassing belicht die ik heb geschreven. Deze toepassing illustreert het nut en gebruik van de parser.

6.2 6.2.1

MPEG-21 REL Parser Algemene beschrijving

Zoals eerder beschreven in het hoofdstuk “Rights Expression Languages”, bestaat MPEG-21 REL uit 3 grote delen, namelijk de “Core”, de “Standard Extension” en de “Multimedia Extension”. De “Core” is het belangrijkste (en tevens grootste) deel van MPEG-21 REL en omvat de basisstructuren om REL-documenten te kunnen aanmaken. De andere twee delen zijn uitbreidingen van de “Core” en hebben vooral betekenis in een digitale context. Vooraleer verder te gaan met de beschrijving van de parser, lijkt het me handig om eerst te vermelden wat een parser juist is. Een parser is een mechanisme dat een tekst 73

“ontleedt” en ze daarna gaat interpreteren. Met een tekst kan bijvoorbeeld een stukje programmacode bedoeld worden, of bijvoorbeeld hier in deze context een tekst in een bepaald formaat. De parser die ik geschreven heb, krijgt als input een REL-document, interpreteert de elementen die in het document beschreven staan en geeft als uiteindelijke output een objectstructuur terug die het document voorstelt. Onderstaande figuur illustreert de algemene werking van de parser.

Figuur 6.1: Omzetting REL-document naar objectstructuur van REL elementen

6.2.2

Doel

Het algemeen doel van de parser is evident: het omzetten van een REL-document in een objectstructuur. Men kan zich de vraag stellen waarom dit nuttig kan zijn: het antwoord is tijdswinst en veralgemening. De winst in tijd is er omdat het telkens moeten parsen van een XML document, met bestaande software zoals een DOM[17] of SAX[54] parser at runtime nogal tijdvergend is (vooral voor grotere documenten). Door deze fase maar ´e´en keer te doen (nl. bij het omzetten in objectstructuur) zal men later verder met de objecten kunnen werken en dus veel tijd winnen. Aangezien men met objecten werkt, krijgt men een algemene structuur van het document waarop men verschillende bewerkingen kan doen. Men kan de objectstructuur dan later gebruiken voor verschillende doeleinden (de objectstructuur laat bijvoorbeeld gemakkelijk validatie van rechten toe, door het gebruik van getter- en settermethodes). Het stuk software dat ik geschreven heb, past als module in de MPEG-21 Terminal. Deze terminal verzamelt alle “parts” van MPEG-21 om uiteindelijk tot ´e´en grote “interpreter” te komen. De bedoeling van de MPEG-21 Terminal is het interpreteren van een DID document (Digital Item Declaration). Dit document bevat veel delen van MPEG-21 zoals DIP ( Digital Item Processing ), DII ( Digital Item Identification) en DIA ( Digital 74

Item Adaptation). Uiteraard is REL ook een belangrijk deel van een DID document. Daar waar delen zoals DIP, DII en DIA vooral gericht zijn op de beschrijving en identificatie van een digitaal object, is REL eerder bedoeld voor het defini¨eren van rechten op het gebruik van een digitaal object.

6.2.3

Technische beschrijving

Algemeen De parser werd geschreven met Borland JBuilder X[3] en dit in een J2ME[32] omgeving. De reden waarom deze parser en in het algemeen de MPEG-21 terminal zelf in J2ME werden geschreven, is het eventueel later gebruik ervan op het terrein van mobiele telefonie. J2ME is wel beperkt in z’n mogelijkheden (er zijn bijvoorbeeld geen voorzieningen voor grafische vormgeving en men kan niet werken met re¨ele getallen). Deze laatste beperking heeft een eerste ontwerpsbeslissing van de parser tot gevolg: alle mogelijke opvraagbare data (zoals count, notBefore, ...) zijn van het String type. Een groot voordeel van het feit dat de parser geschreven is in J2ME, is dat ze gemakkelijk kan overgebracht worden in “hogere” omgevingen, zoals J2SE. Wil men bijvoorbeeld de resultaten van het parsen in een GUI voorstellen, kan dit zonder probleem. De parser die werd gebruikt is een XmlPullParser[70]. Dit is een parser die speciaal ontworpen is voor mobiele toepassingen. Om XML-data te genereren uit de objecten, wordt gebruik gemaakt van een XmlSerializer[70]. Bij de hieropvolgende beschrijving was ik genoodzaakt terug te vallen op methoden en codefragmenten. Om de leesbaarheid van de tekst te bewaren, heb ik ze (daar waar mogelijk) opgenomen in appendix B. Input De parser ontleedt MPEG-21 REL-documenten. Deze documenten zijn opgebouwd in XML zoals in hoofdstuk 2 beschreven. Het REL-document moet syntactisch in orde zijn ( “well formed” ) en moet tevens voldoen aan het Core schema “rel-r.xsd” ( het document moet “valid” zijn). De parser kan alle elementen verwerken die in het Core schema gedefinieerd zijn. Elementen die voldoen aan andere schema’s zoals “Digital Signature”, “XML Encryption” en ook de Standard- en Multimedia Extension worden gewoon geparsed naar 75

objecten die klare tekst bevatten. Ze worden dus niet omgezet in “bruikbare” objecten. Deze objecten zijn zogenaamde PullParseable objecten en bevatten PullParseable data. De elementen in deze data zijn niet manipuleerbaar. Werking MPEG-21 Terminal.java Bij het opstarten van de applicatie wordt de midlet1 geladen die gedefinieerd is in de klasse “MPEG-21 Terminal”. Onderstaande figuren illustreren het verloop van de applicatie.

Figuur 6.2: Gebruik van de MPEG-21 Terminal om een REL-document te parsen

1. Gebruiker klikt op “MPEG-21 Terminal” en klikt op Launch. 2. Gebruiker kiest voor REL en klikt op Run. 3. Het document wordt geparsed en gebruik makende van een XMLSerializer wordt de output naar het scherm geschreven. Tevens wordt ook de tijd weergegeven die nodig was om het document te parsen. Nadat de gebruiker voor REL gekozen heeft, wordt de methode “DoRelTest()” uit de klasse MPEG-21 Terminal geladen. Er wordt een DIDEngine aangemaakt die het inputdocument zal inladen. Na het oproepen van de methode “loadDIDFromLocalStorage” wordt deze DIDEngine ge¨ınitialiseerd. Op dat moment kan het resultaat van het 1

Een midlet is een toepassing die is geschreven voor J2ME MIDP apparaten. Een midlet bestaat uit twee bestanden: een Java Application Descriptor (JAD): een kleine tekst die de toepassing beschrijft en een Java Archive (JAR): de execute file van de toepassing (10 - 100 kbytes of zelfs meer).

76

parsen bijvoorbeeld uitgeschreven worden naar het scherm, door deze DIDEngine mee te geven als parameter aan “System.out.println()”. Het feit waarom men hier vertrekt van deze DIDEngine is reeds eerder aangehaald: het is de bedoeling om een volwaardig DID document te kunnen interpreteren.

Methode loadDIDFromLocalStorage() uit de klasse DIDEngine

Deze methode cre¨eert een XmlPullParser die gebruikt wordt om het REL-document te parsen. Daarna wordt de methode read() van de klasse NsDistributor opgeroepen, die afhankelijk van het type document, het root element van dit document zal inlezen. In ons geval zal dus het root element van een REL-document ingelezen worden, nl. een LicenseGroup of een License. Uit het fragment (opgenomen in appendix B) volgt dat het DID document overlopen wordt, en wanneer men een bepaalde tag tegenkomt, (hier bijvoorbeeld TAG REL), zal men het bijhorende root element construeren en inlezen.

De interface “RELDefinitions” houdt de namen bij van de verschillende elementen die door de parser gebruikt worden om alle delen van het REL-document te identificeren. De elementen zijn namespaces, XSI types, namen van tags, namen van attributen...

De methode “read”

E´enmaal het root element geconstrueerd is, gaat het eigenlijke parsen van start. De methode read() die wordt opgeroepen leest de attributen van het root element in en gaat na of dit element kinderen heeft. Wanneer een kind gevonden wordt, gaat men een object van dit kind construeren en leest men het in. Het kind zal dan op zijn beurt kijken als het zelf kinderen heeft, zal ze construeren en inlezen. Wanneer de huidige positie van de XmlPullParser de eind-tag van het element aangeeft, stopt men het inlezen van het element. Op dat moment is alle informatie die vervat zit in het element geparsed naar objecten. Op deze manier wordt heel het document ingelezen, tot men terug bij het root element komt. Het “overlopen” van het document gebeurt m.b.v. XmlPullParser, die telkens wordt meegegeven aan de read() methode om te weten welke de huidige tag is.

77

De methode “write”

Naast het inlezen van het REL-document en het parsen ervan naar objecten, is het natuurlijk ook interessant om het geparsed resultaat te kunnen uitschrijven. Hiervoor bevat elke klasse die een element uit het “Core” schema voorstelt een write methode. Eerst en vooral schrijft het element zichzelf uit als begin-tag, met eventueel bijhorende ingelezen attributen. Tevens worden ook de namespace en het “xsi-type” van het element uitgeschreven. Daarna gaat men na of het element ingelezen kind-objecten heeft. Als dit het geval is, wordt de methode write van deze objecten opgeroepen. Op deze manier worden alle elementen volgens de hi¨erarchie van het inputdocument uitgeschreven. Uiteindelijk wordt ook een eind-tag uitgeschreven van het “bovenliggend” element. Het uitschrijven van de elementen gebeurt a.d.h.v. een XMLSerializer. Tijdens het programmeren van de parser heb ik telkens het resultaat van het parsen naar het scherm geschreven om de goede werking van de parser te controleren. Een andere mogelijkheid is om het resultaat weg te schrijven in een nieuw REL-document. Ter verduidelijking van de werking van de methoden “read” en “write” vindt u in appendix B de met commentaar voorziene klasse “LicenseGroup”. Output Het resultaat van het parsen is een objectstructuur die het REL-document voorstelt. Met behulp van gettermethoden kan men in deze structuur bvb. nagaan hoeveel “issuers” er in het document beschreven staan, welke de condities zijn waaraan de gebruiker moet voldoen, welke de resource is waaraan de licentie vasthangt, hoeveel keer de houder van de licentie een bepaalde resource mag raadplegen etc. Tevens zijn settermethoden voorzien die vooral handig zijn om waarden van bepaalde tags te gaan veranderen (bvb. de waarde van een “notBefore” element in een ValidityInterval, de waarde van “count” die bepaalt hoeveel keer een gebruiker een resource mag raadplegen... In appendix B vindt u een voorbeeld van een getter- en een settermethode. Deze methoden laten toe om informatie uit REL-documenten op te vragen en eventueel te veranderen. Ze kunnen bijvoorbeeld nuttig gebruikt worden in software die een REL licentie interpreteert (validatie van rechten, analyse van een REL-document...).

78

6.2.4

Hi¨ erarchie Core schema

Ter verduidelijking ziet u hieronder de hi¨erarchie van het Core schema. Deze hi¨erarchie werd gegenereerd m.b.v. het programma xmlspy[71]. De parser kan elk element die in deze hi¨erarchie voorkomt omzetten in een object. De belangrijkste elementen zijn uiteraard LicenseGroup en License. Een LicenseGroup bestaat uit een License. Deze laatste bestaat ofwel uit een sequentie van de elementen Title, Inventory, Grant/GrantGroup, OtherInfo ofwel uit ´e´en EncryptedLicense. Het belangrijkste element uit laatst opgenoemde elementen is uiteraard de Grant. Deze beschrijft het grootste gedeelte van de licentie, ze omvat de Principal, Right, Resource en Condition als voornaamste elementen. Merk op dat onderstaande figuur niet volledig is, enkel License en Issuer worden voorgesteld als voorbeeld. Voor een overzicht van alle klassen van de MPEG-21 REL parser, verwijs ik graag naar appendix A.

Figuur 6.3: Core schema: voorstelling elementen License en Issuer

79

6.2.5

Ontwerpsbeslissingen

Data van het type “String” Opvraagbare data zijn zeer belangrijk in een REL-document: ze verschaffen informatie omtrent het al of niet geldig zijn van een licentie. Wanneer men een REL-document interpreteert, is het ook deze data die men gaat opvragen en vergelijken met andere data (bijvoorbeeld opvragen van de inhoud van de tag notBefore in een ValidityInterval element en deze vergelijken met de huidige tijd). Zoals reeds eerder aangehaald is alle opvraagbare data van het type “String”. De reden waarom ik dit zo heb aangepakt is het feit dat de parser geschreven is in een J2ME omgeving, die vele datatypes niet aankan (zoals bijvoorbeeld het type float). Uiteraard is het mogelijk om later een conversie te doen naar andere types, bijvoorbeeld het omzetten van een String die een geheel getal voorstelt naar dat geheel getal. “Data” klassen De parser is van nature uit een “REL-R parser”. Dit betekent dat hij enkel elementen herkent die in het “Core” schema gedefinieerd zijn. Niettegenstaande het feit dat het “Core” schema zeer uitgebreid is, bevatten vele REL-documenten ook elementen uit andere, al of niet gerelateerde namespaces. Gerelateerd aan het “Core” schema zijn bijvoorbeeld de “Multimedia Extension” en de “Standard Extension”. Deze schema’s defini¨eren elementen die nauwer aansluiten bij digitale objecten (bijvoorbeeld het element “play” uit de Multimeda Extension, of de “fee” constructies uit de Standard Extension). Naast de gerelateerde namespaces hebben we ook niet-gerelateerde zoals “Digital Signature” (dsig)[15] of elementen uit “XML Encryption” (xenc)[69], die zich toespitsen op encryptie en het digitaal signeren van bepaalde delen van REL-documenten. Omdat het onmogelijk is een volledige parser te schrijven die al deze elementen kan interpreteren, heb ik ervoor gekozen ze als “PullparseableData” te gebruiken. Kort betekent dit dat deze elementen niet ge¨ınterpreteerd worden, maar gewoon als data worden opgeslaan. Deze data bevindt zich in zgn. “Data klassen”. Op deze manier kan het document in z’n geheel geparsed worden en zullen deze elementen niet overgeslaan worden. Deze werkwijze was ook noodzakelijk in het kader van de toepassing van de parser: de “REL interpreter module” verwacht een volledig REL-document, dus ook “niet-Core” data. 80

De technische werking is als volgt: nadat alle mogelijke kinderen uit het “Core” schema van het huidige ouder-element bij de read methode overlopen zijn, wordt naar de diepte (reader.getDepth()) van het huidige element gekeken. Wanneer deze diepte groter is dan 1 (m.a.w. we hebben te maken met een kind-element) en het element is een start-tag, dan hebben we te maken met “niet-Core” informatie (we kunnen dit met zekerheid stellen aangezien eerder alle mogelijke “Core-kinderen” werden overlopen). Op dat moment wordt het gepaste “Data-object” aangemaakt en wordt het ingelezen. De methode read van het data object roept dan de methode read op van de klasse PullParseableData die de uiteindelijke data zal inlezen. Ieder “Data-object” bevat ook getter- en settermethoden om het onderliggend PullParseableData-object op te vragen en te manipuleren. Hieronder ziet u een overzicht van de “Data klassen”. 1. AnXmlData.java 2. ConditionData.java 3. DatumData 4. DigitalResourceData.java 5. EncryptionData.java 6. ExerciseMechanism.java 7. InfoData.java 8. IssuerData.java 9. OtherInfoData.java 10. RevocableData.java 11. RevocationMechanismData.java 12. RightData.java 13. SecureData.java 14. TitleData.java 15. TransformsData.java 81

Abstracte - en concrete elementen Een aantal elementen uit het “Core” schema zijn abstract. Dit wil zeggen dat ze door andere elementen vervangbaar of “substitutable” zijn. Het element “Right” bijvoorbeeld kan vervangen worden door de concrete elementen “Issue”, “Obtain”, “Revoke” en “PossessProperty”. Het substitueren van abstracte elementen is een veel voorkomende zaak in REL-documenten, in weinig gevallen wordt het abstracte element zelf gebruikt. Wanneer een abstract element gebruikt wordt dient ze enkel als referentie naar een andere element van dezelfde soort. Het gebruik van een abstract element in een REL-document is dus vrij beperkt. Een abstract element bezit enkel een type attribuut die zegt van welk type het element is, maar het heeft zelf geen kinderen. Hoewel het beperkend karakter van abstracte elementen, voorziet deze parser het gebruik van beide soorten elementen. De voornaamste abstracte elementen zijn “Principal”, “Right”, “Resource” en “Condition”. Onderscheid tussen identieke elementen die op verschillende plaatsen kunnen voorkomen Sommige elementen kunnen verschillende kinderen hebben van dezelfde soort. Het element “Grant” bijvoorbeeld heeft als belangrijkste kinderen de “Principal”, “Right”, “Resource” en “Condition”. Hoewel de abstracte elementen “Principal” en “Resource” verschillend zijn, kunnen ze beide toch gesubstitueerd worden door bijvoorbeeld hetzelfde concreet element “KeyHolder”. Moest men voor het element “KeyHolder” slechts 1 array voorzien, dan zou men na het inlezen geen onderscheid kunnen maken of die bepaalde KeyHolder nu een“Principal” is of een“Resource” waarop eventueel rechten zijn gedefinieerd. Om dit te voorkomen heb ik 2 vectoren gedefinieerd die duidelijk een onderscheid maken tussen de verschillende KeyHolders. Om te weten als een ingelezen KeyHolder nu een “Principal” is of een “Resource”, heb ik gebruik gemaakt van een teller. Deze teller wordt bij aanmaak van het hoofdelement (hier Grant) ge¨ınitialiseerd op nul. Wanneer het eerste KeyHolder element wordt ingelezen, zal dit een Principal zijn (toch in het geval van een correct RELdocument). Op dat moment wordt de Keyholder opgeslaan in de array “myKeyHolder”, en wordt de teller 1 verhoogd. Vervolgens worden de andere elementen ingelezen. Wanneer 82

men verderop in het document opnieuw een KeyHolder tegenkomt, betekent dit dat het element een “Resource” is. De teller wordt gecheckt en als deze groter is dan 1, wordt het KeyHolder element opgeslaan in de array “myKeyHolderAsResource”. Op die manier kan men de Keyholders gemakkelijk van elkaar onderscheiden. Achteraf kan men de KeyHolder elementen gaan opvragen en manipuleren met de gepaste getter- en settermethodes. Deze mehode wordt ook nog voor andere (identieke) elementen toegepast in de parser. Gebruik van de klasse Vector Bij het inlezen van een element worden ingelezen kinderen opgeslaan in vectoren. De reden waarom ik dit doe is twee¨erlei. Ten eerste omdat het aantal kinderen van een element dynamisch is. Men kan bijvoorbeeld niet op voorhand weten hoeveel licenties er vervat zullen zitten in een Licensegroup. Een andere reden is het vergroten van de bruikbaarheid van de parser: wanneer elementen die nu volgens het “Core” schema ´e´en kind hebben en later meerdere kinderen mogen hebben, moet de code niet herzien worden. Wanneer alle kinderen ingelezen zijn, worden de geconstrueerde vectoren omgezet in een array.

6.3

Toepassing

In dit deel ga ik een toepassing bespreken die ik geschreven heb om het nut van de REL parser aan te tonen. De parser wordt als module gebruikt in bestaande MPEG-21 referentiesoftware.

6.4

“REL license interpretation with DID”

De referentiesoftware waarin de parser toegevoegd wordt is “REL license interpretation with DID”. Deze referentiesoftware is nog niet beschikbaar, maar is gepland voor een volgende MPEG meeting.

83

6.4.1

Beschrijving

Figuur 6.4: MPEG-21 REL: REL license interpretation with DID

De software gebruikt reeds eerder besproken referentiesoftware ( zie hoofdstuk 5). De module “REL Interpreter” is exact dezelfde als deze besproken in 5.2.4. Deze laatste module maakt ook nog gebruik van een “License Schema Checker” zoals besproken in 5.2.1. Als input krijgt het systeem een DID document waarin REL informatie vervat zit. Deze REL informatie zit als kind in het “Statement” element van een DID document, zoals in appendix B ge¨ıllustreerd. De REL informatie bevat ook een beschrijving van een “resource” waarop rechten zijn gedefinieerd. In het kort is het de bedoeling deze REL informatie te absorberen uit het DID document en deze door te geven aan de “REL Interpreter” module. Eenmaal dit gebeurd is, zal deze module bepalen m.b.v. de inputquery als de gebruiker al of niet geauthoriseerd is om de resource te gaan gebruiken ( voor een beschrijving van deze laatste fase, zie 5.2.4). Op dezelfde wijze als waarop een REL-document geparsed wordt, zal hier het DID document geparsed worden: //maak een DIDEngine aan DIDEngine myDIDEngine = new DIDEngine(); //lees DID document in InputStreamReader in = new InputStreamReader(new FileInputStream(did.getAbsolutePath())); 84

myDIDEngine.loadDIDFromStreamReader(in); //initialiseer DIDEngine myDIDEngine.initialize(); Vervolgens wordt de REL informatie opgehaald uit het DID document en omgezet naar objectstructuur: //Haal REL object uit het Statement element. De methode ‘‘getInlineData()’’ //geeft ‘‘PullParseable’’ terug. De ‘‘PullParseable’’ kan omgezet worden //naar een License. Op dat moment is heel de License geparsed. License rel = (License)myDIDEngine.getDID().getItem()[0].getDescriptor()[0]... ....getStatement()[0].getInlineData(); Nu we de license informatie hebben, moet ze nog gelinkt worden aan de “REL interpreter” module. Deze laatste module verwacht als input een bestand die een REL-licentie voorstelt. We schrijven de informatie uit het REL object weg naar een tijdelijk bestand, dat dan samen met de inputquery aangelegd wordt aan de “License Interpreter”: //Wegschrijven informatie REL object naar een bestand FileOutputStream fos = new FileOutputStream(temp+sdf.format(cal.getTime())+".tmp"); writer.setOutput(new OutputStreamWriter(fos)); writer.startDocument(null, null); rel.write(writer); writer.endDocument(); license = new File(temp+sdf.format(cal.getTime())+".tmp"); //Aanleggen van license bestand en query aan de //‘‘REL License Interpreter’’ module. RELParserTool parserTool = new RELParserTool(license.getAbsolutePath(), userQuery.getAbsolutePath()); 85

De module “REL Interpreter” is een alleenstaand programma dat normaal werkt via commando-lijn: de license en user query worden via argumenten meegegeven. Om tot ´e´en “programma” te komen heb ik de eigen geschreven parser en het pakket die REL kan interpreteren aan elkaar geweven. Vandaar dat ook in het laatste codefragment rechtstreeks een object aangemaakt wordt van de klasse RELParserTool, dat het interpreteren van het REL-document voor zijn rekening neemt. De klasse Test.java stelt een GUI voor waarin de gebruiker een DID document en een user query kan kiezen. De module “REL Interpreter” genereert eveneens een aantal bestanden wanneer er fouten opgetreden zijn (een log bestand als er fouten zijn opgetreden en een outputbestand die een melding geeft als de conditions al of niet geldig zijn). De gebruiker kan kiezen waar hij deze bestanden wil opslaan. Na het duwen op de knop “OK” kan de gebruiker het hierboven beschreven mechanisme in gang zetten door op de knop “Validate” te drukken. Na afloop wordt het uiteindelijke resultaat (al of niet geauthorizeerd) aan de gebruiker vermeld. De “Exit” knop dient om de applicatie te verlaten. Op de volgende pagina ziet u een snapshot van de applicatie. Hieronder vat ik de referentiesoftware nog eens in het kort samen. Het is duidelijk dat deze toepassing de goede werking van de REL parser bewijst: in plaats van de REL informatie rechtstreeks aan de Interpreter te koppelen, wordt ze eerst via een omweg geparsed naar objectstructuur. Vanuit deze objectstructuur wordt de REL informatie dan opnieuw ge¨extraheerd. Aangezien ik hetzelfde resultaat kreeg op beide manieren (rechtstreeks en via parsing) kon ik besluiten dat de parser goed werkt.

6.4.2

Input

1. DID document (met REL informatie) 2. Query die bestaat uit volgende elementen: principal, right, resource, time, exercise count (optioneel)

6.4.3

Output

Resultaat van authorizatie (al of niet geauthorizeerd) en (optioneel) een logbestand, wanneer fouten optreden. 86

Figuur 6.5: Snapshot REL license interpretation with DID

87

Deel III Algemeen besluit

88

Hoofdstuk 1 Er zijn verschillende beschrijvingen mogelijk om het ruim concept “DRM” te beschrijven. Digital Rights Management bestaat enerzijds uit beveiligingstechnieken (zowel op softals hardwareniveau) voor data en anderzijds uit mechanismen om data te identificeren, te beschrijven en te beschermen door het afdwingen van intellectuele eigendomsrechten. DRM streeft naar het ontwikkelen van een veilig systeem, waarin digitale objecten veilig en snel kunnen uitgewisseld worden tussen producent en consument. DRM werd ingevoerd om immateri¨ele data te kunnen beschermen. Ze heeft vooral haar nut voor de industrie, die haar content op een veilige manier wil verspreiden en een remedie zoekt tegen computerpiraterij. Daarnaast kan DRM ook gebruikt worden voor niet-commerci¨ele doeleinden zoals het beschermen van data van een eindgebruiker of data binnen een bedrijf. Om tot een goed systeem te komen is het concept “standaardisatie” alom aanwezig in de wereld van DRM. Standaardisatie bevordert de communicatie en interoperabiliteit tussen verschillende DRM architecturen en zorgt voor een globale kostenverlaging. Men zou kunnen argumenteren dat het vooral de industrie is die voordeel haalt uit het gebruik van DRM en dat de consument eerder benadeeld wordt. Het gebruik van DRM kent ook een aantal economische gevolgen, waarvan de belangrijkste monopolievorming is. DRM is sterk gerelateerd met de wet: zonder de wet kan DRM niet ingevoerd worden. De wet speelt ook een belangrijke rol in het verminderen van de macht van de producent en op het gebied van beveiliging.

Hoofdstuk 2 Een rights expression language (REL) is een taal die dient om rechten op (digitale) objecten te specificeren en de controle op het gebruik van deze objecten te vergroten. Hiertoe beschikt ze over een eigen grammatica en vocabularium (woordenboek).

89

Naast de XML-gebaseerde RELs (ODRL, XrML, MPEG-21 REL, XMCL en PRL), bestaat er ook een REL die op logische taal gesteund is (LicenseScript). Het moet evenwel opgemerkt worden dat deze laatste REL een eerder experimentele REL is, ze is geen kandidaat om de “standaard REL” te worden. De XML-gebaseerde talen hebben veel mogelijkheden omdat ze steunen op een alom aanwezige standaard die ook gebruikt wordt bij andere mechanismen (beveiliging, metadata). Een tweede voordeel die voortvloeit uit de aanwezigheid van deze standaard is dat XML-gebaseerde talen ook een grotere interoperabiliteit verzekeren. XML-gebaseerde talen hebben evenwel ook een aantal minder goeie karaktertrekken: ze zijn te “menselijk” en syntactisch gezien kunnen ze leiden tot ingewikkelde constructies. Door het gebruik van de logische taal PROLOG beschikt LicenseScript over een formele semantiek, waardoor ze beter interpreteerbaar is door machines. Ook biedt ze mogelijkheden die niet aanwezig zijn bij de XML-gebaseerde talen, zoals licentie-evolutie. Het grootste nadeel van LicenseScript is dat het nogal “een eiland” op zichzelf is, ze kan bijvoorbeeld geen gebruik maken van andere standaarden voor bepaalde functionaliteiten.

Hoofdstuk 3 In de praktijk zijn er verschillende DRM architecturen. Sommige worden gebruikt voor commerci¨ele doeleinden (bijvoorbeeld Windows Media Player), anderen worden dan weer gebruikt voor niet-commerci¨ele doeleinden (zoals het beschermen van informatie binnen een bedrijf). Het is echter wel duidelijk dat deze systemen een aantal gemeenschappelijke kenmerken hebben, ze vertonen een algemene gemeenschappelijke architectuur. Ze proberen zoveel mogelijk aan standaardisatie te doen door de werking van het systeem te beperken tot eigen gedefinieerde formaten. De licenties worden van de data gescheiden voor twee redenen. Ten eerste kan men op die manier aan ´e´en digitaal object verschillende licenties toekennen en ten tweede laat deze scheiding toe om meerdere businessmodellen te defini¨eren op dezelfde data. Het “copyright” probleem kan architecturaal opgelost worden door een bijkomende server te voorzien die aan de hand van een externe “rights data server” toegevoegde rechten valideert. Deze rights data server bevat rechten op gebruik van data die volgens de wet beschreven zijn. Hierdoor zal de macht van de producent verminderen.

90

Een DRM architectuur moet ook nog een aantal andere subsystemen hebben zoals modellering, beschrijving en identificatie van entiteiten, alsook een vorm van communicatie. Al deze componenten samen verhogen de uiteindelijke interoperabiliteit tussen verschillende DRM architecturen.

Hoofdstuk 4 Uit de besproken beveiligingstechnieken blijkt dat vooral hardware een oplossing kan bieden om de intellectuele eigendomsrechten op digitale data te beschermen, en om dus een grotere winst te boeken voor de industrie. Het doorvoeren van hardwaretechnieken is economisch zeer moeilijk, omdat er nood is aan een standaardisatie binnen de hardwaresector (alle hardwareproducenten moeten de hardwaretechnieken ondersteunen). Hoewel bovenstaande beveiligingstechnieken de piraterij enigszins kunnen tegengaan, blijven toch nog een aantal problemen onoverkomelijk. Ten eerste blijft het analoog kopi¨eren van data nog altijd mogelijk. Dit probleem is niet zo ernstig aangezien analoge kopies van mindere kwaliteit zijn dan digitale kopies. Het onmogelijk maken van exacte digitale kopies zou de piraterij sterk kunnen remmen. Ten tweede zal het altijd mogelijk blijven om in de “supply chain” van producent naar consument data te gaan onderscheppen, en hoe moeilijk dit ook mag zijn, deze data te gaan decrypteren. Het Internet is nu eenmaal van nature uit een onveilig medium. Uit de beveiligingsinbraken blijkt dat de technieken niet altijd even veilig zijn en dat er zeker nog veel onderzoek moet gedaan worden om een veilig systeem te kunnen ontwikkelen.

Hoofdstuk 5 Op het gebied van MPEG-21 is er reeds een groot aanbod aan referentiesoftware aanwezig. Deze referentiesoftware heeft betrekking op REL en RDD. De software werkt over het algemeen goed, hoewel ze in vele gevallen nogal beperkt is. Ze zijn bedoeld als onderzoek in de hoop dat ze een steentje kunnen bijdragen aan de verdere ontwikkeling van DRM.

91

Hoofdstuk 6 In dit hoofdstuk wordt de MPEG-21 parser besproken die ik heb geschreven. Als tweede deel wordt een toepassing van deze parser besproken, nl. het invoegen van deze parser in referentiesoftware.

92

Bijlage A

1. AllConditions.java 2. AllPrincipals.java 3. AnXml.java 4. AnXmlData.java 5. AnXmlExpression.java 6. AnXmlPatternAbstract.java 7. Binary.java 8. Condition.java 9. ConditionData.java 10. ConditionIncremental.java 11. ConditionPattern.java 12. ConditionPatternAbstract.java 13. ConditionUnchanged.java 14. Count.java 15. Datum.java 16. DatumData.java

93

17. DcConstraint.java 18. DelegationControl.java 19. DepthConstraint.java 20. Details.java 21. DigitalResource.java 22. DigitalResourceData.java 23. EncryptedContent.java 24. EncryptedGrant.java 25. EncryptedGrantGroup.java 26. EncryptedLicense.java 27. EncryptionData.java 28. ExerciseMechanism.java 29. ExerciseMechanismData.java 30. ExerciseService.java 31. ExistsRight.java 32. ForAll.java 33. FulFiller.java 34. Grant.java 35. GrantGroup.java 36. GrantGroupPattern.java 37. GrantPattern.java 38. Info.java 39. InfoData.java 94

40. Inventory.java 41. Issue.java 42. Issuer.java 43. IssuerData.java 44. KeyHolder.java 45. License.java 46. LicenseGroup.java 47. LicenseId.java 48. LicensePart.java 49. NonSecureIndirect.java 50. NotAfter.java 51. NotBefore.java 52. Obtain.java 53. OtherInfo.java 54. OtherInfoData.java 55. PatternFromLicensePart.java 56. PossessProperty.java 57. PrerequisiteRight.java 58. Principal.java 59. PrincipalPattern.java 60. PrincipalPatternAbstract.java 61. PriorToStart.java 62. PropertyAbstract.java 95

63. PropertyPossessor.java 64. RELDefinitions.java 65. RELObject.java 66. RELUtil.java 67. Resource.java 68. ResourcePattern.java 69. ResourcePatternAbstract.java 70. Revocable.java 71. RevocableData.java 72. RevocationFreshness.java 73. RevocationMechanism.java 74. RevocationMechanismData.java 75. RevocationService.java 76. RevocMechanism.java 77. Revoke.java 78. Right.java 79. RightData.java 80. RightPattern.java 81. RightPatternAbstract.java 82. SecureData.java 83. SecureIndirect.java 84. ServiceDescription.java 85. ServiceParameters.java 96

86. ServiceReference.java 87. TimeOfIssue.java 88. Title.java 89. TitleData.java 90. ToConstraint.java 91. Transforms.java 92. TransformsData.java 93. TrustedRootGrants.java 94. TrustedRootIssuers.java 95. TrustRoot.java 96. ValidityInterval.java 97. WholeGrantExpression.java 98. WholeGrantGroupExpression.java

97

Bijlage B

methode doRELtest() private void doRELtest() { ... // DID Engine DIDEngine myDIDEngine = new DIDEngine(); myDIDEngine.loadDIDFromLocalStorage("/res/REL.xml"); myDIDEngine.initialize(); ... //prints parsed REL document to screen System.out.println(myDIDEngine); ... } methode loadDIDFromLocalStorage() public void loadDIDFromLocalStorage(String location) { try { XmlPullParser reader = this.createXmlPullParser(); InputStreamReader in = new InputStreamReader(getClass().getResourceAsStream(location)); reader.setInput(in);

98

if (this.findDIDL(reader)) { myDID = (DIDL) NsDistributor.read(reader, null); } else { throw new Exception("DIDL Element not found"); } in.close(); } catch (Exception e) { System.out.println(e); } } Fragment uit de klasse NsDistributor.java ... // REL namespace else if (reader.getEventType() == reader.START_TAG && reader.getNamespace().equals(RELDefinitions.NS_REL)) { // REL start tag if (reader.getName().equals(RELDefinitions.TAG_REL)) { LicenseGroup licenseGroup = new LicenseGroup(); licenseGroup.read(reader); return licenseGroup; } // License starttag else if (reader.getName().equals(RELDefinitions.TAG_LICENSE)) { License license = new License(); license.read(reader); 99

return license; } ... klasse Licensegroup (voorzien van commentaar) package org.iso.mpeg.mpeg21.rel; import import import import

java.io.*; java.util.*; org.iso.mpeg.*; org.xmlpull.v1.*;

/** * Een Java representatie van het LicenseGroup . * * De klasse RELObject is een klasse die een algeen element voorstelt, * ze definieert de methoden read en write. Deze kunnen door overerving * ingevuld worden. De interface PullParseable wordt door ieder element * gebruikt en definieert de methoden read() en write(). **/ public class LicenseGroup extends RELObject implements PullParseable { /** Private veranderlijke die de namespace van het element bijhoudt **/ private String myTypeNS = null; /** Private veranderlijke die het type van het element bijhoudt **/ private String myType = null; /** * Een LicenseGroup heeft maar 1 mogelijke soort kinderen, nl. een License. * De veranderlijke myLicense houdt deze kinderen bij, als er zijn. **/

100

private License [] myLicense = new License[0]; /** * Constructs a LicenseGroup Object. */ public LicenseGroup() { super(); } // Getter en setter methoden om attributen en kinderen te kunnen opvragen // en te manipuleren. /** * Gets the License children of the current LicenseGroup Object. * * @return Returns an array with the License children of the current * LicenseGroup Object. The return value is an array with length 0 * if no such children exist. */ public License[] getLicense() { return myLicense; } /** * Sets the License children of the current LicenseGroup Object. * * @param description An array containing the License children of the * current LicenseGroup object. This array should be of length 0 if * no such children exist. */ public void setLicense(License[] license) { 101

myLicense = license; } /** * Gets the type of the current Object. * * @return Returns the type of the current Object. * The return value is null if no type is given. */ public String getType() { return myType; } /** * Sets the type of the current Object. * * @param type the type of the current Object. * This parameter should be null if no type exist. */ public void setType(String type) { myType = type; } /** * Gets the TypeNamespace of the current Object. * * @return Returns the TypeNamespace of the current Object. * The return value is null if no such children exist. */ public String getTypeNamespace() { return myTypeNS; 102

} /** * Sets the TypeNamespace of the current Object. * * @param typeNamespace The typeNamspace of the current Object. * This object should be null if no such children exist. */ public void setTypeNamespace(String typeNamespace) { myTypeNS = typeNamespace; } /** * Initializes the class by reading from an XmlPullParser. * * @param reader An initialized XmlPullParser object. * @throws IOException * @throws XmlPullParserException */ public void read(XmlPullParser reader) throws IOException, XmlPullParserException { //inlezen van type en typeNamespace // read the Type myType = RELUtil.readType(reader); // read the TypeNamespace myTypeNS = RELUtil.readTypeNameSpace(reader); //Vector die license-kinderen bijhoudt 103

Vector licenseVector = new Vector(); /** * Overlopen van de kinderen van het element. Hier stelt TAG_REL * het element "LicenseGroup" voor.Zolang geen eind-tag van het * element LicenseGroup wordt herkend door de XMLPullParser reader, * gaat men na of er license kinderen zijn. M.b.v. de methode reader.next() * wordt naar de volgende tag gesprongen. **/ reader.next(); while (! (reader.getEventType() == reader.END_TAG && reader.getNamespace().equals(RELDefinitions.NS_REL) && reader.getName().equals(RELDefinitions.TAG_REL))) { //license if ( reader.getEventType() == reader.START_TAG && reader.getNamespace().equals(RELDefinitions.NS_REL) && reader.getName().equals(RELDefinitions.TAG_LICENSE) ) { License license = new License(); license.read(reader); licenseVector.addElement(license); } else { reader.next(); } } // De vector wordt omgezet naar een array myLicense= new License[licenseVector.size()]; 104

licenseVector.copyInto(myLicense); } } /** * Writes the current class using an XmlSerializer. * * @param writer An initialized XmlSerializer object. * @throws IOException * @throws IllegalArgumentException * @throws IllegalStateException */ public void write(XmlSerializer writer) throws IOException, IllegalArgumentException, IllegalStateException { //Uitschrijven van start tag writer.startTag(RELDefinitions.NS_REL, RELDefinitions.TAG_REL); //Uitschrijven xsi type attribuut en andere attributen RELUtil.writeXSIType(myType, myTypeNS, writer); writer.attribute(null,RELDefinitions.SX,RELDefinitions.NS_SX); writer.attribute(null,RELDefinitions.MX,RELDefinitions.NS_MX); writer.attribute(null,RELDefinitions.DSIG,RELDefinitions.NS_DSIG); writer.attribute(null,RELDefinitions.XSI,RELDefinitions.NS_XSI); writer.attribute(null,RELDefinitions.XSILOC,RELDefinitions.NS_XSILOC); //Uitschrijven van license kinderen, als er zijn. for (int i = 0; i < myLicense.length; i++) { myLicense[i].write(writer); } //Uitschrijven eind-tag writer.endTag(RELDefinitions.NS_REL, RELDefinitions.TAG_REL); } 105

} Voorbeeld van een getter methode /** * Gets the License children of the current LicenseGroup Object. * * @return Returns an array with the License children of the current * LicenseGroup object. The return value is an array with length 0 * if no such children exist. */ public License[] getLicense() { return myLicense; } Voorbeeld van een setter methode /** * Sets the notBeforeValue of the current Object. * * @param type the type of the current Object. * This parameter should be null if no type exist. */ public void setNotBeforeValue(String notBefore) { notBeforeValue = notBefore; }

106

Een eenvoudig DID document <Statement mimeType="text/xml"> ... REL informatie ...

107

Bijlage C

Figuur 1: LicenseScript: voorbeeld

108

Figuur 2: ODRL: voorbeeld van een offer

109

Figuur 3: MPEG-21 REL / XrML: voorbeeld van een “Use License”

110

Referenties [1]

Adobe Acrobat Reader. http://www.adobe.com/products/acrobat/readermain.html

[2]

Adobe Systems Incorporated. Adobe and Digital Content for eCommerce, September 1999. http://www.adobe.com/products/acrobat/webbuy/pdfs/eBookWP2.pdf

[3]

Borland JBuilder. http://www.borland.com/jbuilder/

[4]

CEN ISSS. Digital Rights Management Final Report, 2003.

[5]

Chong, C. et al. Comparing logic-based and xml-based Rights Expression Languages, 2002. https://doc.telin.nl/dscgi/ds.py/Get/File-33671/comparison.pdf

[6]

[XrML] Content Guard’s Extensible Rights Markup Language. http://www.xrml.org

[7]

[CPRM] Content Protection for Recordable Media. http://www.4centity.com/tech/cprm

[8]

ContentGuard. http://www.contentguard.com

[9]

[DMCA] Digital Millennium Copyright Act. www.copyright.gov/legislation/dmca.pdf

[10] [DOI] Digital Object Identifier. http://www.doi.org 111

[11] [DPRL] Digital Property Rights Language. http://xml.coverpages.org/dprl.html [12] Digital Rights Management and Privacy (EPIC). http://www.epic.org/privacy/drm/default.html [13] Ianella, R. Digital Rights Management Architectures. D-Lib Magazine 7(6), 2001. [14] Rosenblatt, B. et al. Digital Rights Management: Business and Technology, John Wiley & sons, New York, 2001. [15] [DSIG] Digital Signature. http://www.w3.org/DSig/DSigGenInfo.html [16] Digital Watermarking World: Introduction. http://www.watermarkingworld.org/intro.html [17] [DOM] Domain Object Model. http://www.w3.org/DOM/ [18] DRM Watch. http://www.drmwatch.com/ [19] Dublin Core. http://dublincore.org [20] [ONIX] EDItEUR ONIX International Standard. http://www.editeur.org/onix.html [21] [EUCD] EU Copyright Directive. http://www.eurorights.org/eudmca [22] [XML Schema] Extended Markup Language Schema. http://www.w3.org/TR/2001/REC-xmlschema-0-20010502 [23] [XMCL] Extended Media Commerce Language. http://www.xmcl.org/ [24] Guth, S. et al. A Contract and Rights Management Framework Design for Interacting Brokers, 2003. http://wi.wu-wien.ac.at/Wer sind wir/Guth/C+RMgmtFrameworkDesign.pdf 112

[25] Infomarket (IBM). urlhttp://www.ibm.com [26] [IMS] IMS Learning Resource Meta-data Information Model (Version 1.1). http://www.imsproject.org/metadata/mdinfov1p1.pdf [27] [IFLA] International Federation of Library Associations. http://www.ifla.org/VII/s13/frbr/frbr.htm [28] [ISBN] International Standard Book Number. www.isbn.org [29] [ISTC] International Standard Text Code http://www.nlc-bnc.ca/iso/tc46sc9/wg3.htm [30] [INDECS] Interoperability of data in e-commerce systems. http://www.indecs.org [31] Intertrust (Electronic Publishing Resources). http://www.intertrust.com [32] [J2ME] Java 2 Micro Edition. http://java.sun.com/j2me/ [33] LicenseScript. http://wwwes.cs.utwente.nl/licensescript [34] [MARC] MARC Code List for Relators. http://lcweb.loc.gov/marc/relators/re0003r2.html [35] [NGSCB] Microsoft Next-Generation Computing Base. http://www.microsoft.com/resources/ngscb/default.mspx [36] [MPEG] Moving Pictures Expert Group. http://www.chiariglione.org/mpeg/index.htm [37] MPEG 21. http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm [38] [MPEG REL-21] MPEG-21 Rights Expression Language (MPEG-21 part 5). http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm 113

[39] [ODRL] Open Digital Rights Language. http://odrl.net [40] Open Digital Rights Language (ODRL) version 1.1. http://www.w3.org/TR/odrl/ [41] [OEBF] Open eBook Forum. http://www.openebook.org [42] [OASIS] Organization for the Advancement of Structured Information Standards. http://www.oasis-open.org/home/index.php [43] [PRL] PRISM Rights Language. http://xml.coverpages.org/prism.html [44] [PRISM] Publishing Requirements for Industry Standard Metadata. http://www.prismstandard.org/ [45] QuickTime iTunes. http://www.apple.com/itunes/ [46] Real Helix DRM. http://www.realnetworks.com/products/drm [47] Real Player. www.real.com [48] [RIAA] Recording Industry Artists of America. http://www.riaa.com [49] Rein, L. Comparing rights expression languages, 2002. http://www.lisarein.com/rightslang.html [50] [RDF] Resource Description Framework. www.w3.org/RDF [51] [VCARD] RFC 2426 vCard Profile. http://www.ietf.org/rfc/rfc2426.txt [52] RightsExpress. http://rightsexpress.contentguard.com 114

[53] Saarinen, V. et al. NONIUS: implementing a DRM system , 2002. http://www.hiit.fi/reports/hiit2002-3.pdf [54] [SAX] Simple API for XML. http://www.saxproject.org/ [55] [SDMI] Secure Digital Music Interactive. http://www.sdmi.org [56] [SSSCA] Secure Systems Standard and Certification Act. http://www.eff.org [57] Rightscom. The MPEG-21 Rights Expression Language - a white paper. http://www.rightscom.com/files/MPEG21 RELwhite paper.pdf [58] Trusted Computing FAQ 1.1. http://home.wanadoo.nl/squell/tcpa-faq.html [59] [TCG] Trusted Computing Group. https://www.trustedcomputinggroup.org [60] [URI] Uniform Resource Identifier. http://www.ietf.org [61] [UDDI] Universal Discovery, Description, and Integration. http://www.uddi.org [62] [W3C] World Wide Web Consortium. http://www.w3.org [63] [WSDL] Web Services Description Language. http://www.w3.org/TR/wsdl [64] Windows Media 9 series Digital Rights Management. http://www.microsoft.com/windows/windowsmedia/drm.aspx [65] Windows Media Player. http://www.microsoft.com/windows/windowsmedia/default.aspx

115

[66] Windows Media Rights Manager. http://www.microsoft.com/windows/windowsmedia/wm7/drm/architecture. aspx [67] Windows Rights Managing Services. http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/ default.mspx [68] [XeroX PARC] Xerox Palo Alto Research Center. http://www.parc.xerox.com [69] XML Encryption. http://www.w3.org/Encryption/2001/ [70] XMLPullParser & XMLSerialzer. http://www.xmlpull.org/v1/doc/api/index.html [71] xmlspy. http://www.xmlspy.com/ [72] XrML Technical Overview version 1.0 (ContentGuard). http://www.xrml.org/Reference/XrMLTechnicalOverviewV1.pdf

116