NO329299B1 - Domene-baserte tillitsmodeller for rettighetsforvaltning av innhold - Google Patents

Description

Oppfinnelsen vedrører systemer for forvaltning av digitale rettigheter. Spesielt vedrører oppfinnelsen anvendelse av tillitsmodeller for å definere hvem som kan motta en lisens for et stykke rettighetsforvaltet innhold, og hvem som kan utstede slik en lisens.

Digital rettighetsforvaltning ("DRM", digital rights management) samt håndheving av slike rettigheter er sterkt ønskelig i forbindelse med digitalt innhold så som digital lyd, digital video, digital tekst, digitale data, digitale multimedier, etc, der slikt digitalt innhold skal distribueres til én eller flere brukere. Digitalt innhold kan være statisk, så som for eksempel et tekstdokument, eller det kan være streamet, så som streamet lyd/video for en "levende" hendelse. I en typisk anvendelse av et rettighetsforvaltningssystem mottar en bruker et stykke digitalt innhold over et nettverk (f.eks. Internett) eller på et fysisk medium (f.eks. på en disk). I tillegg, dersom brukeren tillates å "konsumere" innholdet (f.eks. spille av lyd- eller videoinnhold, se tekstinnhold, eksekvere programvaren, etc), mottar brukeren også en lisens for dette innholdet. Rettighetsforvaltningssystemet håndhever kravet om at brukeren skal kunne konsumere innholdet bare når slik konsumering tillates av betingelsene i lisensen.

Rettighetsforvaltningssystemer anvender typisk kryptografi i minst to sammenhenger. For det første blir innhold som skal beskyttes kryptert. For det andre, gitt at enhver meningsfull anvendelse av kryptert innhold krever dekrypteringsnøkkelen, må nøklene kun bli distribuert til pålitelige entiteter, og kryptografiske sertifikater og signaturer blir anvendt for å etablere denne tilliten.

I det enkleste rettighetsforvaltningssystem verifiserer eieren av kryptert innhold direkte påliteligheten til konsumenten av dette innholdet, og, dersom eieren stoler på konsumentens pålitelighet, distribuerer en lisens som inneholder dekrypteringsnøkkelen til den konsumenten. Et slikt system tilveiebringer imidlertid ikke tilstrekkelig funksjonalitet til å være av særlig kommersiell interesse. Det meste av innhold - i likhet med alt annet innenfor handel - blir distribuert gjennom en kompleks kjede eller et nett av relasjoner. For eksempel kan innholdseieren delegere til en distributør oppgaven med å utstede lisenser (og således nøkler) for innhold. I dette tilfellet gir atskillelsen av innholdseier og lisensdistributør større fleksibilitet med hensyn til hvordan innhold blir distribuert (for eksempel trenger ikke innholdseieren å bruke tid eller penger på å distribuere innhold og drifte en lisenserver). På den annen side krever denne atskillelsen også at innholdseieren (som har eierinteresser i innholdet) stoler på lisensdistributøren (som har mulighet for å påvirke eierens proprietære interesse).

Andre aspekter ved distribusjons/rettighetsforvaltningsprosessen kan også skilles ut. For eksempel, når lisensgiveren utsteder en lisens som tillater en bruker å konsumere et stykke innhold på en spesifikk maskinvare-plattform, tar lisensgiveren implisitt en avgjørelse vedrørende: (a) brukerens identitet (dersom lisensen er begrenset til spesifikke brukere), og (b) sikkerheten til den plattformen på hvilken innholdet vil bli rendret. Lisensgiveren kan ta denne avgjørelsen direkte, men det kan være nyttig å la en annen entitet (en "identitetsutsteder" eller "identitetsserver") utstede et sertifikat som attesterer slik identitet og plattformsikkerhet, og at lisensgiveren ganske enkelt bare stoler på dette sertifikatet. Denne dekoplingen krever imidlertid implisitt at lisensgiveren stoler på utstederen av identitetssertifikatet, ettersom fortsatt kontroll over innholdet avhenger av at et slikt sertifikat ikke blir utstedt til en bedrager eller for en ikke-klarert plattform. Et annet aspekt ved distribusjons- og rettighetsforvaltningsprosessen som kan skilles ut er at den entiteten som definerer de omstendighetene under hvilke en lisens kan bli utstedt kan være forskjellig fra den entiteten som faktisk utsteder lisensen. Når innhold blir publisert, kan således en første entitet digitalt signere en rettighetsspesifikasjon som spesifiserer lisensbetingelsene, og en andre entitet kan faktisk utstede lisensen som muliggjør anvendelse av innholdet. Igjen krever denne typen dekopling at den første entiteten stoler på at den andre entiteten bare utsteder lisenser under de spesifiserte betingelser.

Det kan forstås fra den foregående diskusjonen at den praktiske realiteten vedrørende hvem som kan lisensiere et dokument og under hvilke omstendigheter kan påvirkes av hvem som stoler på hvem. Mangfoldet av hvem som kan oppnå en lisens for innhold kan utvides (eller innskrenkes) ved å utvide (eller inndra) tillit mellom forskjellige servere som deltar i distribusjons- og lisensieringsprosessen.

US 6,398,245 B1 beskriver et nøkkelforvaltningssystem for en spiller for digitalt innhold, samt en fremgangsmåte for forvaltning av nøkler som benyttes av en slik spiller i et datamaskinsystem. I henhold til fremgangsmåten dekrypteres digitale innholdsdata som er kryptert med en første krypteringsnøkkel, med en første dekrypteringsnøkkel, og re-krypteres ved å benytte en andre krypteringsnøkkel. En andre dekrypteringsnøkkel krypteres ved å benytte en tredje krypteringsnøkkel for å produsere en kryptert andre derypteringsnøkkel.

WO 01/98903 A1 angår fremgangsmåte og systemer for å fordele innhold via et nettverk som anvender distribuerte tilgangssystem-agenter og sikkerhetsagenter, og for å utføre digital rettighetsforvaltning (DRM). Innholdstilbyderen tilveiebringer autorisasjon til innholdsdistributøren for å utføre operasjonen, og autorisasjonen er spesifikk for innholdsdistributøren.

Foreliggende oppfinnelse tilveiebringer en teknikk for anvendelse av pålitelighet for å styre tilgang til innhold som ikke har blitt realisert i tidligere teknikk.

Oppfinnelsen tilveiebringer systemer og fremgangsmåter som anvender en tillitsmodell for å påvirke hvordan og under hvilke omstendigheter rettighetsforvaltet innhold blir lisensiert.

I et første aspekt tilveiebringer oppfinnelsen en fremgangsmåte for lisensiering av innhold, omfattende de trinn å: motta en forespørsel for en lisens, idet lisensforespørselen omfatter et identitetsssertifikat for en entitet til hvilken lisensen skal utstedes og identitetssertifikatet angir en utsteder av sertifikatet i sertifikatet; og bestemme om utstederen av identitetssertifikatet er pålitelig;

bestemme at betingelsene for å lisensiere innholdet til entiteten er til stede;

generere lisensen for den entiteten som skal anvende innholdet; og sende lisensen til entiteten;

kjennetegnet ved at:

hvor bestemmelsen om at utstederen av identitetssertifikatet (1004) er pålitelig omfatter: å bestemme om utstederen utsteder identitetssertifikater til offentligheten basert på e-postadresser og passord, idet sertifikatet angir en e-postadresse;

å bestemme at hverken e-postadressen eller domenenavnet som identifiseres av e-postadressen, finnes på en ekskluderingsliste.

I et andre aspekt tilveiebringer oppfinnelsen et datamaskinlesbart medium som inneholder datamaskin-eksekverbare instruksjoner for å utføre fremgangsmåten angitt over.

I et tredje aspekt tilveiebringer oppfinnelsen et system for lisensiering av innhold omfattende: en liste av pålitelige entiteter; en lisensutstedermodul som mottar en lisensforespørsel omfattende et identitetssertifikat for en identitet som en lisens skal bli utstedt til, som bestemmer hvorvidt identitetssertifikatet er utstedt av en av de pålitelige entitetene, som bestemmer hvorvidt betingelsene for lisensiering av innholdet er oppfylt, og som utsteder en lisens dersom identitetssertifikatet er utstedt av en av de pålitelige entitetene og dersom betingelsene for lisensiering av innholdet er oppfylt; kjennetegnet ved at bestemmelsen om at utstederen av identitetssertifikatet er pålitelig omfatter: å bestemme om utstederen utsteder identitetssertifikater til offentligheten basert på epostadresser og passord, idet sertifikatet angir en epost-adresse;

å bestemme at hverken epostadressen eller domenenavnet som identifiseres av epost-adressen, finnes på en ekskluderingsliste.

Et digitalt rettighetsforvaltnings(DRM)-system i henhold til oppfinnelsen publiserer innhold på en slik måte at det bare kan anvendes av en entitet til hvilken innholdet er lisensiert. Innhold som skal DRM-beskyttes blir kryptert og deretter publisert med en "signert rettighetsspesifikasjon". Den signerte rettighetsspesifikasjonen inneholder, blant annet: (a) rettighetsdata, som definerer hvorledes innholdet kan bli anvendt og til hvem det kan bli lisensiert; (b) dekrypteringsnøkkelen for innholdet, kryptert (enten direkte eller indirekte) med fellesnøkkelen til den serveren som utstedte rettighetsspesifikasjonen; og (c) den digitale signaturen til den serveren som utstedte rettighetsspesifikasjonen. Hver entitet (f.eks. en person, en avdeling i en bedrift, en frivillig organisasjon, etc.) som potensielt vil kunne motta rettighetsforvaltet innhold oppnår et "entitetssertifikat" som definerer denne entitetens identitet. Entitetssertifikatet inneholder: (a) et fellesnøkkel/privatnøkkel-par, og (b) signaturen til den serveren som utstedte entitetssertifikatet.

En forespørsel om å lisensiere innhold omfatter den signerte rettighetsspesifikasjonen for innholdet og entitetssertifikatet til den entiteten til hvilken lisensen skal bli utstedt. Når en DRM-lisenserver mottar en slik forespørsel, bestemmer den hvorvidt entitetssertifikatet er signert av en server som lisensgiveren stoler på. (Lisensgiveren kan for eksempel ønske å sikre at serveren vil være tilstrekkelig streng i verifikasjonen av entitetens identitet før den utsteder et slikt sertifikat.) Dersom lisenserveren stoler på den som signerte entitetssertifikatet, bestemmer lisenserveren deretter hvorvidt den kan utstede en lisens på vegne av den entiteten som har signert rettighetsspesifikasjonen. Generelt kan en lisenserver utstede lisenser basert på: (a) rettighetsspesifikasjoner som serveren selv har utstedt, og (b) andre DRM-servere som har delt sin private nøkkel med lisenserveren. (En lisensserver trenger den private nøkkelen til den serveren som utstedte rettighetsspesifikasjonen fordi rettighetsspesifikasjonen omfatter innhold-dekrypteringsnøkkelen kryptert med den utstedende serverens fellesnøkkel; siden en lisens inneholder innhold-dekrypteringsnøkkelen kryptert med entitetssertifikatets fellesnøkkel, trenger lisenserveren den aktuelle private nøkkelen for å dekryptere innholdsnøkkelen slik at innholdsnøkkelen kan rekrypteres med entitetssertifikatets fellesnøkkel.)

Operatøren av en DRM-server kan utvide (eller innskrenke) den gruppen av personer til hvem innhold kan bli lisensiert - og på annen måte påvirke distribusjonsskjemaets topologi - ved å bestemme hvilke andre servere vil bli klarert og hvilke ikke vil bli klarert. Disse avgjørelsene kan anvendes i forbindelse med forskjellige eksempler på tillitsmodeller.

I et første eksempel kan tillitsavgjørelser bli anvendt for å implementere et "pålitelige-personer-domene", der en DRM-server opprettholder en liste av servere som er klarert for å utstede entitetssertifikater. Dette skjemaet kan være nyttig dersom to organisasjoner ønsker at deres medlemmer skal kunne dele rettighetsforvaltet informasjon. Dersom bedrift A og bedrift B begge utsteder entitetssertifikater for sine egne ansatte, kan disse bedriftene enes om å stole på hverandres identitetsservere. En ansatt hos bedrift A kan således publisere innhold som kan lisensieres til en ansatt hos bedrift B, og omvendt. Den ansatte hos bedrift B som mottar innhold som har blitt publisert av en ansatt hos bedrift A presenterer rettighetsspesifikasjonen og sitt eget entitetssertifikat for bedrift A sin DRM-lisensserver; denne lisensserveren vil ha mulighet til å lisensiere innholdet til den ansatte i bedrift B sitt entitetssertifikat ettersom de to bedriftene har blitt enige om å stole på hverandres identitetsservere. Én variasjon av dette eksemplet er der en DRM-lisensserver generelt stoler på en offentlig epostadresse-basert identitetsserver (så som en MICROSOFT .NET PASSPORT-server), bortsett fra i forbindelse med sertifikater som denne serveren har utstedt til en spesifikk person (f.eks. joe@untraceableaddress.com) eller et domene (f.eks. alle adresser fra untraceableaddress.com). Enda mer generelt kan det for en hvilken som helst identitetsserver i pålitelige-personer-domenet være generert en liste av utestengelser basert på epost-adresse, domene eller en annen identifikator, slik at en lisensserver generelt kan stole på en identitetsserver mens den luker ut spesifikke unntak fra denne tilliten.

I et andre eksempel kan tillitsavgjørelser bli anvendt for å implementere et "pålitelig-dokument-domene". I dette tilfellet kan en første DRM-server utstede lisenser basert på rettighetsspesifikasjoner som er generert av en andre DRM-server ved å oppnå den andre DRM-serverens private nøkkel. Effektivt betyr en slik transaksjon at den andre DRM-serveren gir den første DRM-serveren tillit til å utstede lisenser på vegne av den andre serveren. Dette skjemaet kan være nyttig dersom to avdelinger innenfor en bedrift hver opprettholder en DRM-server (f.eks. dersom de to avdelingene er geografisk atskilte). I dette tilfellet kan hver avdeling ønske å publisere innhold som den andre avdelingen kan lisensiere på sin egen DRM-server - f.eks. publiserer en ansatt ved avdeling A innhold ved anvendelse av avdeling A sin DRM-server og sender det publiserte innholdet, sammen med den signerte rettighetsspesifikasjonen, til en ansatt ved avdeling B; den ansatte ved avdeling B sender da den signerte rettighetsspesifikasjonen til avdeling B sin DRM-server for å oppnå en lisens. Dette scenariet kan muliggjøres ved å tilveiebringe avdeling A sin private nøkkel til avdeling B sin DRM-server.

Andre særtrekk ved oppfinnelsen er beskrevet nedenfor.

Den foregående oppsummeringen, så vel som den følgende detaljerte beskrivelsen av foretrukne utførelsesformer, blir bedre forstått når de leses i sammenheng med de vedlagte figurene. For det formål å illustrere oppfinnelsen er det i figurene vist eksempler på konstruksjoner ifølge oppfinnelsen; oppfinnelsen er imidlertid ikke begrenset til de spesifikke metoder, mekanismer og anordninger som er beskrevet.

Figur 1 er et blokkdiagram som illustrerer et eksempel på ikke-begrensende datamiljø i hvilket foreliggende oppfinnelse kan bli implementert. Figur 2 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for å publisere digitalt innhold. Figur 3 er et blokkdiagram som viser strukturen til en signert rettighetsspesifikasjon som generert av fremgangsmåten i figur 3. Figur 4 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for lisensiering av rettighetsforvaltet digitalt innhold. Figurene 5A og 5B viser et flytdiagram av en foretrukket utførelsesform av en fremgangsmåte ifølge oppfinnelsen for lisensiering av rettighetsforvaltet digitalt innhold. Figur 6 er et blokkdiagram av en plattform med kryptografisk funksjonalitet som støtter et rettighetsforvaltningssystem i henhold til særtrekk ved oppfinnelsen; Figur 7 er et blokkdiagram av et eksempel på identitetssertifikat i henhold til aspekter ved oppfinnelsen; Figur 8 er et blokkdiagram av et eksempel på lisens i henhold til aspekter ved oppfinnelsen; Figur 9 er et blokkdiagram som viser relasjonen mellom nøkkelbeskyttelseslag og en tillitskjede; Figur 10 er et blokkdiagram som viser selektiv klarering av identitetsservere i henhold til aspekter ved oppfinnelsen; Figur 11 er et blokkdiagram av anvendelseeksempelet med pålitelige-personer-domener for å muliggjøre deling av dokumenter mellom to organisasjoner; Figur 12 er et blokkdiagram av et eksempel på arkitektur som omfatter en offentlig epost-basert identitetsserver i henhold til aspekter ved oppfinnelsen; Figur 13 er et blokkdiagram som viser deling av en privat nøkkel for å gi en første DRM-server mulighet til å lisensiere innhold på vegne av en annen DRM-server i henhold til aspekter ved oppfinnelsen; Figur 14 er et blokkdiagram av anvendelseseksempelet med et pålitelig-dokument-domene for å muliggjøre krysslisensiering av beskyttet innhold mellom to avdelinger i en bedrift; og Figur 15 er et flytdiagram som viser et eksempel på prosess for å validere tillit for lisensforespørseler, i henhold til aspekter ved oppfinnelsen.

Eksempel på databehandlingsmiljø

Figur 1 og den følgende beskrivelsen er ment for å tilveiebringe en kort, generell beskrivelse av et egnet databehandlingsmiljø i hvilket oppfinnelsen kan bli implementert. Det skal imidlertid forstås at håndholdte, bærbare og andre dataanordninger av alle typer er mulige for anvendelse i forbindelse med foreliggende oppfinnelse. Selv om en generell datamaskin er beskrevet nedenfor, er dette kun ett eksempel, og foreliggende oppfinnelse krever kun en tynn klient som har nettverkstjener-interoperabilitet og -vekselvirkning. Foreliggende oppfinnelse kan således bli implementert i et miljø av nettverksomfattede tjenester der veldig lite eller minimalt med klientressurser er påkrevet, f.eks. et nettverksmiljø der klientanordningen kun tjener som en browser eller et grensesnitt mot World-Wide-Web.

Selv om det ikke er nødvendig kan oppfinnelsen være implementert via et API (applikasjon-programming-interface) for anvendelse av en utvikler og/eller omfattet i nettleser-programvaren som vil bli beskrevet i den generelle sammenhengen datamaskin-eksekverbare instruksjoner, så som programmoduler, som eksekveres av én eller flere datamaskiner, så som klient-arbeidsstasjoner, tjenere eller andre anordninger. Generelt omfatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer og liknende som utfører spesifikke oppgaver eller implementerer spesifikke abstrakte datatyper. Funksjonaliteten til programmodulene kan typisk kombineres eller distribueres som ønsket i forskjellige utførelsesformer. Videre vil fagmannen forstå at oppfinnelsen kan praktiseres med andre datasystem-konstruksjoner. Andre velkjente datasystemer, -miljøer og/eller -konstruksjoner som kan være egnet for anvendelse med oppfinnelsen omfatter, men er ikke begrenset til, personlige datamaskiner (PC-er), automatiserte kassaapparater, tjenerdatamaskiner, håndholdte eller laptop-anordninger, flerprosessorsystemer, mikroprosessorbaserte systemer, programmerbar forbrukerelektronikk, personlige datamaskiner i nettverk, minidatamaskiner, stormaskiner og liknende. Oppfinnelsen kan også anpasses for distribuerte databehandlingsmiljøer der oppgaver blir utført av fjernlokaliserte prosesseringsanordninger som er forbundet gjennom et kommunikasjonsnettverk eller et annet dataoverføringsmedium. I et distribuert databehandlingsmiljø kan programmoduler være lokalisert i både lokale og fjernlokaliserte datamaskin-lagringsmedier som omfatter

minnelagringsanordninger.

Figur 1 illustrerer således et eksempel på et egnet datamiljø 100 i hvilket oppfinnelsen kan bli implementert, selv om, som presisert ovenfor, datamiljøet 100 bare er ett eksempel på et egnet datamiljø og ikke er ment for å antyde noen begrensning vedrørende oppfinnelsens bruksområde eller funksjonalitet. Heller ikke skal datamiljøet 100 fortolkes å ha noen som helst avhengighet eller krav vedrørende noen enkelt eller kombinasjon av komponenter som er illustrert i det eksemplifiserte datamiljøet 100.

Med henvisning til figur 1 omfatter et eksempel på system for å implementere oppfinnelsen en generell databehandlingsanordning i form av en datamaskin 110. Komponenter av datamaskin 110 kan omfatte, men er ikke begrenset til, en prosesseringsenhet 120, et systemminne 130 og en systembuss 121 som kopler forskjellige systemkomponenter omfattende systemminnet til prosesseringsenheten 120. Systembussen 121 kan være en hvilken som helst av mange typer busstrukturer, omfattende en minnebuss eller minnekontroller, en periferenhet-buss og en lokal buss, som anvender en hvilken som helst av en rekke tilgjengelige bussarkitekturer. Som eksempler, og uten begrensning, omfatter slike arkitekturer en ISA (Industry-Standard-Architecture)-buss, en MCA (Micro-Channel- Architecture)-buss, en EISA (Enhanced ISA)-buss, en lokal VESA (Video-Electronics-Standards-Association)-buss, og en PCI (Peripheral-Component-lnterconnect)-buss (også kjent som en Mezzanine-buss).

Datamaskinen 110 omfatter typisk flere datamaskinlesbare medier. Datamaskinlesbare medier kan være et hvilket som helst tilgjengelig medium som kan aksesseres av datamaskinen 110, og omfatter både volatile og ikke-volatile medier samt flyttbare og ikke-flyttbare medier. Som eksempler, uten begrensning, kan datamaskinlesbare medier omfatte datamaskin-lagringsmedier og kommunikasjonsmedier. Datamaskin-lagringsmedier omfatter både volatile og ikke-volatile, flyttbare og ikke-flyttbare medier som er realisert med en hvilken som helst fremgangsmåte eller teknologi for lagring av informasjon så som datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data. Datamaskin-lagringsmedier omfatter, men er ikke begrenset til, RAM, ROM, EEPROM, flash-minne eller annen minneteknologi, CDROM, DVD (digital-versatile-disk) eller andre optisk-disk lagre, magnetkasetter, magnetbånd, magnetdisklagre eller andre magnet-lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å lagre den ønskede informasjonen og som kan aksesseres av datamaskinen 110. Kommunikasjonsmedier inneholder typisk datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal så som en bærebølge eller en annen transportmekanisme, og omfatter ethvert informasjonsleveringsmedium. Med betegnelsen "modulert datasignal" menes et signal som får én eller flere av sine karakteristika satt eller endret for det formål å innkode informasjon i signalet. Som et eksempel, og uten begrensning, omfatter kommunikasjonsmedier kablede medier så som et kabelnettverk eller en direktekoplet forbindelse, samt trådløse medier så som akustiske, RF-baserte, infrarøde og andre trådløse medier. Enhver kombinasjon av det ovennevnte er også omfattet innenfor rammen av datamaskinlesbare medier.

Systemminnet 130 omfatter datamaskin-lagringsmedier i form av volatilt og/eller ikke-volatilt minne så som et leseminne (ROM) 131 og et direkteaksessminne (RAM) 132. Et BIOS (basic input/output system) 133, som inneholder de grunnleggende rutinene som overfører informasjon mellom elementer i datamaskinen 110, for eksempel under oppstart, er typisk lagret i ROM 131. RAM 132 inneholder typisk data og/eller programmoduler som er umiddelbart tilgjengelige for og/eller som opereres på av prosesseringsenheten 120. Som et eksempel, og uten begrensning, illustrerer figur 1 et operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137.

Datamaskinen 110 kan også omfatte andre flyttbare/ikke-flyttbare, volatile/ikke-volatile datamaskin-lagringsmedier. Kun som et eksempel illustrerer figur 1 en harddiskstasjon 141 som leser fra eller skriver til ikke-flyttbare, ikke-volatile magnetiske medier, en magnetdiskstasjon 151 som leser fra eller skriver til en flyttbar, ikke-volatil magnetdisk 152 og en optisk-disk stasjon 155 som leser fra eller skriver til en flyttbar, ikke-volatil optisk disk 156, så som et CD-ROM eller et annet optisk medium. Andre flyttbare/ikke-flyttbare, volatile/ikke-volatile datamaskin-lagringsmedier som kan anvendes i det eksemplifiserte driftsmiljøet omfatter, men er ikke begrenset til, magnetbåndkassetter, flashminnekort, DVD-plater, digitale bildebånd, statisk RAM, statisk ROM og liknende. Harddiskstasjonen 141 er typisk koplet til systembussen 121 via et ikke-flyttbart minne-grensesnitt, så som grensesnittet 140, og magnetdiskstasjonen 151 og optisk-disk stasjonen 155 er typisk koplet til systembussen 121 via et flyttbart minne-grensesnitt, så som grensesnittet 150.

De stasjonene og deres assosierte datamaskin-lagringsmedier som er diskutert ovenfor og illustrert i figur 1 tilveiebringer lagring av datamaskinlesbare instruksjoner, datastrukturer, programmoduler og andre data for datamaskinen 110.1 figur 1, for eksempel, er harddiskstasjonen 141 vist som lagrende et operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147. Merk at disse komponentene enten kan være de samme som eller forskjellige fra operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137. Operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147 er gitt forskjellige referansenummer her for å illustrere det at de i det minste er forskjellige kopier. En bruker kan entre kommandoer og informasjon til datamaskinen 110 via innmatingsanordninger så som et tastatur 162 og en pekeranordning 161, vanligvis omfattende en mus, en styreball eller en berøringsmatte. Andre innmatingsanordninger (ikke vist) kan omfatte en mikrofon, styrespak, spillkontroll, parabolantenne, skanner eller liknende. Disse og andre innmatingsanordninger er ofte koplet til prosesseringsenheten 120 via et brukerinnmatingsgrensesnitt 160 som er koplet til systembussen 121, men kan også være tilkoplet via andre grensesnitts- og busstrukturer, så som en parallellport, en spillutgang eller en universell seriell buss (USB-port).

En monitor 191 eller en annen type skjermanordning er også koplet til systembussen 121 via et grensesnitt, så som et skjermkort 190. Et grafikk-grensesnitt 182, så som Northbridge, kan også være koplet til systembussen 121. Northbridge er et chipset som kommuniserer med CPU-enheten, eller vertsprosesseringsenheten 120, og tar ansvaret for akselerert grafikkport(AGP)-kommunikasjonen. Én eller flere grafikkprosesseringsenheter (GPU-enheter) 184 kan kommunisere med grafikk-grensesnittet 182.1 denne henseende omfatter GPU-enhetene 184 generelt intern (on-chip) minnelagring, så som registerlagring, og GPU-enhetene 184 kommuniserer med et videominne 186. GPU-enhetene 184 er imidlertid kun ett eksempel på en koprosessor, og det kan således være inkludert en rekke forskjellige koprosesseringsanordninger i datamaskinen 110. En monitor 191 eller en annen type skjermanordning er også koplet til systembussen 121 via et grensesnitt, så som et skjermkort 190, som i sin tur kan kommunisere med videominnet 186.1 tillegg til monitoren 191 kan datamaskiner også omfatte andre periferi-utmatingsanordninger så som høyttalere 197 og en skriver 196, som kan være tilkoplet via et periferienhet-utmatingsgrensesnitt 195.

Datamaskinen 110 kan operere i et nettverket miljø via logiske forbindelser til én eller flere fjerndatamaskiner, så som en fjerndatamaskin 180. Fjerndatamaskinen 180 kan være en personlig datamaskin, en server, en ruter, en nettverks-PC, en peer-anordning eller en annen vanlig nettverksnode, og omfatter typisk mange av eller alle de elementene som er beskrevet ovenfor i forbindelse med datamaskinen 110, selv om kun en minnelagringsanordning 181 er illustrert i figur 1. De logiske forbindelsene som er vist i figur 1 omfatter et lokalt nettverk (LAN) 171 og et fjernaksessnett (WAN) 173, men kan også omfatte andre typer nettverk. Slike nettverksmiljøer er vanlige i kontorer, bedriftsomspennende datanettverk, intranett og Internett.

Når den anvendes i et LAN-nettverksmiljø, er datamaskinen 110 forbundet til LAN 171 via et nettverksgrensesnitt eller nettverkskort 170. Når den anvendes i et WAN-nettverksmiljø, omfatter datamaskinen 110 typisk et modem 172 eller andre anordninger for å etablere kommunikasjon over WAN 173, for eksempel Internett. Modemet 172, som kan være internt eller eksternt, kan være koplet til systembussen 121 via brukerinnmatingsgrensesnittet 160 eller en annen dertil egnet mekanisme. I et nettverksmiljø kan programmoduler som er vist i forbindelse med datamaskinen 110, eller deler av disse, være lagret i den fjernlokaliserte minnelagringsanordningen. Som et eksempel, og uten begrensning, illustrerer figur 1 fjern-applikasjonsprogrammer 185 som lagret i minneanordningen 181. En vil forstå at de viste nettverksforbindelsene kun er eksempler, og at det kan anvendes andre mekanismer for å etablere en kommunikasjonslink mellom datamaskinene.

Publisering av digitalt innhold

Figur 2 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for å publisere digitalt innhold. "Publisering", som denne termen anvendes her, refererer til en prosess som en applikasjon eller tjeneste følger for å etablere med en pålitelig eller klarert entitet et sett av rettigheter og betingelser som entiteten kan utstede for dette innholdet, så vel som til hvem disse rettigheter og betingelser kan bli utstedt. Ifølge oppfinnelsen omfatter publiseringsprosessen det å kryptere det digitale innholdet og assosiere en liste av persistente håndhevbare rettigheter som innholdets forfatter ønsker for alle mulige brukere av innholdet. Denne prosessen kan utføres på en sikker måte for å hindre aksess til noen av rettighetene eller til innholdet dersom dette ikke er tiltenkt av innholdets forfatter.

I en foretrukket utførelsesform av oppfinnelsen kan spesielt tre entiteter bli anvendt for å publisere sikkert digitalt innhold: en innhold-klargjøringsapplikasjon 302 som kjører på klienten 300 og klargjør innholdet for publisering, et DRM-(digital rights management)-API 306 som også befinner seg på klientanordningen 300 og en DRM-server 320 som er kommuniserbart koplet til klienten 300 via et kommunikasjonsnettverk 330.1 en foretrukket utførelsesform av oppfinnelsen omfatter kommunikasjonsnettverket 330 Internett, selv om det må forstås at kommunikasjonsnettverket 330 kan være et hvilket som helst lokalt nettverk eller fjernaksessnett, for eksempel et proprietært intranett.

Innholdklargjøringsapplikasjonen 302 kan være en hvilken som helst applikasjon som produserer digitalt innhold. For eksempel kan applikasjonen 302 være en tekstbehandler eller en annen publiserer som produserer digitale tekstfiler, digital musikk, video eller annet slikt innhold. Innholdet kan også omfatte streamet innhold, så som streamet lyd/video for en "levende" hendelse eller et opptak. Ifølge oppfinnelsen ber innholdklargjøringsapplikasjonen brukeren derav om å kryptere innholdet ved anvendelse av en nøkkel (CK) som brukeren tilveiebringer. Applikasjonen 302 anvender nøkkelen til å kryptere det digitale innholdet, og danner på denne måte en kryptert digital innholdsfil 304. Klientapplikasjonen ber også brukeren om å tilveiebringe rettigheter for den digitale innholdsfilen 304. Rettighetsdataene omfatter en respektiv identitet for hver entitet som har rettigheter vedrørende det digitale innholdet. En slik entitet kan for eksempel være et individ, en klasse av individer eller en anordning. For hver slik entitet omfatter rettighetsdataene også en liste av rettigheter som denne entiteten har vedrørende innholdet og hvilke som helst betingelser som kan være lagt på en hvilken som helst av eller alle disse rettighetene. Slike rettigheter kan omfatte rettighet til å lese, editere, kopiere, skrive ut, etc. det digitale innholdet. I tillegg kan rettigheter være inklusive eller eksklusive. Inklusive rettigheter angir at en spesifisert bruker har en spesifisert rettighet vedrørende innholdet { for eksempel at brukeren kan editere det digitale innholdet). Eksklusive rettigheter angir at en spesifisert bruker har alle rettigheter vedrørende innholdet bortsett fra de som er spesifisert ( for eksempel kan brukeren gjøre hva som helst med det digitale innholdet bortsett fra å kopiere det).

I henhold til én utførelsesform av oppfinnelsen kan klient-API 306 sende det krypterte digitale innholdet og rettighetsdataene til DRM-serveren 320. Ved anvendelse av en prosess som er beskrevet i detalj nedenfor, bestemmer DRM-server 320 hvorvidt den kan håndheve de rettigheter som brukeren har overdratt, og i så fall signerer DRM-serveren 320 rettighetsdataene og genererer en signert rettighetsspesifikasjon (SRL, signed rights label) 308. Generelt imidlertid, kan en hvilken som helst pålitelig entitet signere rettighetsdataene, fortrinnsvis ved anvendelse av en nøkkel som er klarert av DRM-serveren 320. For eksempel kan en klient signere rettighetsdataene ved anvendelse av en nøkkel som er tilveiebragt til den av DRM-serveren 320.

Rettighetsspesifikasjonen 308 kan omfatte data som representerer rettighetsbeskrivelsen, den krypterte innholdsnøkkelen og den digitale signaturen over rettighetsbeskrivelsen og den krypterte innholdsnøkkelen. Dersom DRM-serveren signerer rettighetsspesifikasjonen, sender den den signerte rettighetsspesifikasjonen 308 tilbake til klienten gjennom klient-API 306, som lagrer den signerte rettighetsspesifikasjonen 308 på klientanordningen 300. Innholdsklargjøringsapplikasjonen 302 assosierer deretter den signerte rettighetsspesifikasjonen 308 med den krypterte digitale innholdsfilen 304. For eksempel kan SRL 308 bli sammenkjedet med den krypterte digitale innholdsfilen for å danne en rettighetsforvaltet innholdsfil 310. Generelt trenger imidlertid ikke rettighetsdataene være kombinert med det digitale innholdet. For eksempel kan rettighetsdataene være lagret på et kjent sted, og en referanse til de lagrede rettighetsdataene kan bli kombinert med det krypterte digitale innholdet. Referansen kan omfatte en identifikator som angir hvor rettighetsdataene er lagret ( f. eks. datalageret som inneholder rettighetsdataene) og en identifikator som svarer til disse konkrete rettighetsdataene i dette konkrete lagringsområdet (som for eksempel identifiserer filen som inneholder de spesifikke rettighetsdataene som er av interesse). Det rettighetsforvaltede innholdet 310 kan deretter bli levert til hvem som helst hvor som helst, og bare de entiteter som har rettighet til å konsumere innholdet kan konsumere innholdet, og bare i henhold til de rettigheter de er overdratt.

SRL 308 er et digitalt signert dokument, hvilket gjør det sikkert mot integritetskrenkelser. I tillegg er SRL 308 uavhengig av den faktiske nøkkeltypen og -algoritmen anvendt for å kryptere innholdet, men opprettholder den sterke 1-1 relasjonen til innholdet den beskytter. Nå med henvisning til figur 3, i én utførelsesform av foreliggende oppfinnelse, kan SRL 308 omfatte informasjon om det innholdet som er grunnlaget for SRL 308, muligens omfattende en identifikator for innholdet; informasjon om DRM-serveren som signerer SRL 308, omfattende (PU-DRM(DESI)) og henvisningsinformasjon så som en URL for å utpeke DRM-serveren i et nettverk og tilbakekallinformasjon i tilfelle URL-adressen feiler; informasjon som beskriver SRL 308 selv; (DESI(rightsdata)): (DES1(CK)); og S (PR-DRM), blant annet.

Ved å sikre at en pålitelig entitet signerer rettighetsdataene for å skape en signert rettighetsspesifikasjon 308, sikrer DRM-serveren at den vil utstede lisenser for innholdet i overensstemmelse med betingelsene angitt av publisereren, som beskrevet i rettighetsdataene i rettighetsspesifikasjonen 308. Som en forstår er en bruker nødt til å oppnå en lisens for å rendre innholdet, spesielt ettersom lisensen inneholder innholdsnøkkelen (CK). Når en bruker ønsker å oppnå en lisens for det krypterte innholdet, kan brukeren fremsette en lisensforespørsel omfattende SRL 308 for innholdet og et sertifikat som verifiserer brukerens akkreditiver for DRM-serveren 320 eller en annen lisensutstedende entitet. Den lisensutstedende entiteten kan deretter dekryptere

(PU-DRM(DES1))og (DESI(rightsdata)) for å produsere rettighetsdataene, liste alle de rettigheter som er overdratt av forfatteren (hvis noen) til den lisensforespørrende entiteten og generere en lisens med kun disse spesifikke rettighetene.

Fortrinnsvis, når applikasjonen 302 mottar SRL 308, sammenkjeder applikasjonen 302 den signerte rettighetsspesifikasjonen 308 med den motsvarende (CK(content)) 304 for å generere rettighetsforvaltet digitalt innhold. Alternativt kan rettighetsdataene lagres på et kjent sted, med en referanse til dette stedet tilveiebragt med det krypterte digitale innholdet. En rendringsapplikasjon med DRM-støtte kan således utforske den signerte rettighetsspesifikasjonen 308 via det innholdet som rendringsapplikasjonen forsøker å rendre. Denne utforskingen trigger rendringsapplikasjonen til å initiere en lisensforespørsel til DRM-lisensserveren 320.

Publiseringsapplikasjonen 302 kan for eksempel lagre en URL til DRM-lisensserveren 320, eller DRM-lisensserveren 320 kan innlemme sin egen URL

i form av metadata i rettighetsspesifikasjonen før den signererer den digitalt, slik at DRM-klient API-et 306 som blir kalt av rendringsapplikasjonen kan identifisere den korrekte DRM-lisensserveren 320. Fortrinnsvis legges det inn en unik identifikator, for eksempel en globalt unik identifikator (GUID), i rettighetsspesifikasjonen før den blir signert.

I en foretrukket utførelsesform av oppfinnelsen kan SOAP (simple object access protocol) bli anvendt for kommunikasjon mellom

innholdbeskyttelsesapplikasjonen 302 eller rendringsapplikasjonen og DRM-serveren 320. I tillegg kan det være tilveiebragt API-biblioteker, så som API 306, slik at applikasjoner så som applikasjonen 302 ikke trenger å implementere klientsiden av DRM-protokollen, men i stedet bare kan kalle lokale API-funksjoner. Fortrinnsvis blir XrML, et XML-språk, anvendt for å beskrive rettighetsbeskrivelser, lisenser og rettighetsspesifikasjoner for digitalt innhold, selv om det må forstås at et hvilket som helst egnet format kan anvendes for rettighetsbeskrivelsen og andre data.

Oppnåelse av en lisens for det publiserte innholdet

Figur 4 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for å lisensiere rettighetsforvaltet digitalt innhold. "Lisensiering", som denne termen blir anvendt her, refererer til en prosess som en applikasjon eller tjeneste følger for å forespørre og motta en lisens som vil tillate en entitet som er angitt i lisensen å konsumere innholdet i overensstemmelse med betingelsene spesifisert i lisensen. Inndata til lisensieringsprosessen kan omfatte den signerte rettighetsspesifikasjonen (SRL) 308 som er assosiert med det innholdet for hvilket det etterspørres en lisens, samt fellesnøkkel-sertifikatet/sertifikatene til den eller de entitetene for hvilke lisensen etterspørres. Merk at den entiteten som ber om en lisens ikke nødvendigvis er den entiteten for hvilken lisensen blir etterspurt. En lisens omfatter typisk rettighetsbeskrivelsen fra SRL 308, en kryptert nøkkel som kan dekryptere det krypterte innholdet samt en digital signatur fra lisensserveren over rettighetsbeskrivelsen og den krypterte nøkkelen. Den digitale signaturen sikrer at de angitte entiteter og rettigheter er legitime.

Én måte for applikasjonen 302 å konsumere det rettighetsforvaltede innholdet 310 er at klient-API 306 videresender den signerte rettighetsspesifikasjonen 308 for det rettighetsforvaltede innholdet 310 til DRM-serveren 320 via kommunikasjonsnettverket 330. Lokasjonen til DRM-serveren 320 kan for eksempel finnes i henvisningsinformasjonen i SRL 308. I en slik

utførelsesform kan DRM-lisensserveren 320, via en prosess som er beskrevet i detalj nedenfor, anvende rettighetsbeskrivelsen i rettighetsspesifikasjonen for å bestemme hvorvidt den kan utstede en lisens og, i så fall, for å avlede rettighetsbeskrivelsen som skal inkluderes med lisensen. Som beskrevet ovenfor inneholder rettighetsspesifikasjonen 308 innholdsnøkkelen (CK) kryptert i henhold til fellesnøkkelen til DRM-serveren 320 (PU-DRM) ( dvs. (PU-DRM(CK))). I prosessen med å utstede en lisens dekrypterer DRM-serveren 320 på en sikker måte denne verdien for å oppnå (CK). Den anvender deretter fellesnøkkelen (PU-ENTITY) i det fellesnøkkel-sertifikatet som er sendt inn i lisensforespørselen til å rekryptere (CK) ( dvs. (PU-ENTITY(CK))). Den akkurat krypterte (PU-ENTITY(CK)) er hva serveren 320 plasserer i lisensen. Lisensen kan således returneres til kalleren uten risiko for å eksponere (CK), ettersom kn innehaveren av den assosierte private nøkkelen (PR-ENTITY) kan oppnå (CK) fra (PU-ENTITY(CK)). Klient-API 306 anvender deretter (CK) for å dekryptere det krypterte innholdet for å generere dekryptert digitalt innhold 312.

Klientapplikasjonen 302 kan da anvende det dekrypterte digitale innholdet 312 i henhold til de rettigheter som er overdratt i lisensen.

Alternativt kan en klient, for eksempel den publiserende klienten, utstede sin egen lisens for å konsumere innholdet. I en slik utførelsesform kan det bli kjørt en sikret prosess på klient-datamaskinen som tilveiebringer klienten med den eller de nøklene som er nødvendige for å dekryptere det digitale innholdet under legale omstendigheter.

Figurene 5A og 5B viser et flytdiagram av en foretrukket utførelsesform av en fremgangsmåte 600 ifølge oppfinnelsen for lisensiering av rettighetsforvaltet digitalt innhold. Ifølge oppfinnelsen kan en forespørrende entitet sende inn en lisensforespørsel på vegne av én eller flere potensielle lisensmottakere. Den forespørrende entiteten kan, men trenger ikke være én av de potensielle lisensmottakerne. En potensiell lisensmottaker kan være en person, en gruppe, en anordning eller en hvilken som helst annen slik entitet som kan konsumere innholdet på en hvilken som helst måte. Fremgangsmåten 600 vil nå bli beskrevet i forbindelse med en utførelsesform der en DRM-server prosesser lisensforespørselen, selv om det må forstås at prosesseringen av lisensforespørselen også vil kunne bli utført på, og lisenser bli utstedt av, klienten.

I trinn 602 mottar en lisensutstedende entitet, for eksempel en DRM-server, en lisensforespørsel. En lisensforespørsel omfatter fortrinnsvis enten et fellesnøkkel-sertifikat eller en identitet for hver av én eller flere entiteter for hvilke det bes om lisens.

I trinn 604 autentiseres den forespørrende entiteten ( dvs. den entiteten som fremsetter lisensforespørselen). I henhold til én utførelsesform av oppfinnelsen kan den lisensutstedende entiteten være innrettet for å anvende protokoll ( f. eks. challenge-response)-autentisering for å bestemme identiteten til den forespørrende entiteten, eller den kan være innrettet for ikke å kreve autentisering av den forespørrende entiteten (også kjent som å "tillate anonym autentisering"). Når autentisering er nødvendig, kan en hvilken som helst type autentiseringsskjema bli anvendt { f. eks. challenge-response skjemaet nevnt ovenfor, et bruker-id-og-passord skjema så som MICROSOFT.NET, PASSPORT, WINDOWS authorization, x509, etc). Fortrinnsvis muliggjøres anonym autentisering, så vel som støtte for et hvilket som helst protokollautentiseringsskjema som støttes av integrerte informasjonssystemer. Resultatet av autentiseringstrinnet vil være en identitet, for eksempel en "anonym" identitet (for anonym autentisering) eller identiteten til en personlig konto. Dersom lisensforespørselen av en eller annen grunn ikke kan bli autentisert, blir det returnert en feilmelding, og ingen lisens blir gitt.

I trinn 606 autoriseres den autentiserte entiteten - dvs. at det blir bestemt hvorvidt den identiteten som ble autentisert i trinn 604 har tillatelse til å be om en lisens (enten for seg selv eller på vegne av en annen entitet). Fortrinnsvis lagrer den lisensutstedende entiteten en liste over entiteter som tillates (eller ikke tillates) å be om en lisens. I en foretrukket utførelsesform er en identitet på denne listen av identiteter identiteten til den entiteten som fremsetter forespørselen, heller enn identiteten til den entiteten for hvilken det bes om lisens, selv om begge er mulige. For eksempel kan en personlig konto-identitet ikke ha tillatelse til å fremsette en lisensforespørsel direkte, men en klarert serverprosess kan fremsette en lisensforespørsel på vegne av en slik entitet.

Ifølge oppfinnelsen kan lisensforespørselen omfatte enten et fellesnøkkel-sertifikat eller en identitet for hver potensielle lisensmottaker. Dersom det spørres etter lisens for kun én lisensmottaker, er kun ett sertifikat eller én identitet angitt. Dersom det spørres etter lisens for flere lisensmottakere, kan et sertifikat eller en identitet være angitt for hver potensielle lisensmottaker.

Fortrinnsvis har den lisensutstedende entiteten et fellesnøkkel-sertifikat for hver gyldige lisensmottaker. Det kan imidlertid forekomme at en applikasjon 302 ønsker å generere en lisens for en gitt bruker for hvilken applikasjonen 302 ikke har tilgang til fellesnøkkel-sertifikatet. I et slikt tilfelle kan applikasjonen 302 spesifisere brukerens identitet i lisensforespørselen, og som følge av dette kan den lisensutstedende entiteten kalle opp en registrert sertifikat-innpluggingsmodul som slår opp i en katalogtjeneste og returnerer den aktuelle brukerens fellesnøkkel-sertifikat.

Dersom, i trinn 608, den utstedende entiteten detekterer at fellesnøkkel-sertifikatet ikke er inkludert i lisensforespørselen, anvender da den utstedende entiteten den spesifiserte identiteten for å slå opp i en katalogtjeneste eller database for det aktuelle fellesnøkkel-sertifikatet. Dersom, i trinn 610, den utstedende entiteten bestemmer at sertifikatet finnes i katalogen, hentes da sertifikatet i trinn 612.1 en foretrukket utførelsesform blir en sertifikat-innpluggingskomponent anvendt for å oppnå fellesnøkkel-sertifikater fra en katalog-tjeneste via en katalogaksessprotokoll. Dersom et sertifikat ikke finnes for en gitt potensiell lisensmottaker, hverken i forespørselen eller i katalogen, genererer ikke lisensserveren noen lisens for denne potensielle lisensmottakeren, og i trinn 614 blir en feilmelding returnert til den forespørrende entiteten.

Antatt at den lisensutstedende entiteten har et fellesnøkkel-sertifikat for i hvert fall én potensiell lisensmottaker, validerer deretter, i trinn 616, den utstedende entiteten påliteligheten til lisenssertifikatene. Den utstedende entiteten er fortrinnsvis tilveiebragt med et sett av pålitelige sertifikatutstedersertifikater, og den bestemmer hvorvidt utstederen av lisenssertifikatene finnes på listen av pålitelige utstedere. Dersom, i trinn 616, den utstedende entiteten bestemmer at utstederen av lisenssertifikatet ikke finnes på listen av pålitelige utstedere, avvises da forespørselen for denne lisensmottakeren, og det genereres en feilmelding i trinn 614. På denne måte vil ingen potensiell lisensmottaker hvis sertifikat ikke er utstedt av en pålitelig utsteder motta en lisens.

I tillegg validerer den utstedende entiteten fortrinnsvis den digitale signaturen til alle entiteter i sertifikatkjeden, gående fra de pålitelige utstedersertifikatene til de individuelle lisensmottakernes fellesnøkkel-sertifikater. Prosessen med å validere de digitale signaturene i en kjede er en velkjent algoritme. Dersom fellesnøkkel-sertifikatet for en gitt potensiell lisensmottaker ikke er gyldig, eller et sertifikat i kjeden ikke er gyldig, blir ikke den potensielle lisensmottakeren klarert, og det utstedes derfor ikke noen lisens til denne potensielle lisensmottakeren. Ellers, i trinn 618, kan det utstedes en lisens. Prosessen gjentas i trinn 620 inntil alle entiteter for hvilke det er bedt om en lisens er prosessert.

Som vist i figur 5B fortsetter den lisensutstedende entiteten med å validere den signerte rettighetsspesifikasjonen 308 som er mottatt i lisensforespørselen. I en foretrukket utførelsesform kan den utstedende entiteten anvende en rettighetsspesifikasjon-innpluggingskomponent og en bakenforliggende database for å lagre på serveren en master-kopi av hver rettighetsspesifikasjon som er signert av den utstedende entiteten. Rettighetsspesifikasjonene identifiseres av GUI D-en som ble tillagt dem ved publiseringen. Under lisensieringen (i trinn 622) parser den utstedende entiteten den rettighetsspesifikasjonen som ble sendt inn med lisensforespørselen og henter ut GUID-en deri. Den sender deretter denne GUID-en til rettighetsspesifikasjon-innpluggingskomponenten, som retter en forespørsel til databasen for å hente ut en kopi av master-rettighetsspesifikasjonen. Master-rettighetsspesifikasjonen vil kunne være nyere enn den kopien av rettighetsspesifikasjonen som ble sendt inn med lisensforespørselen, og det vil være denne rettighetsspesifikasjonen som blir anvendt i forespørselen i trinnene nedenfor. Dersom ingen rettighetsspesifikasjon blir funnet i databasen basert på GUID-en, sjekker den utstedende entiteten sitt regelsett, i trinn 624, for å bestemme hvorvidt den likevel tillates å utstede en lisens basert på rettighetsspesifikasjonen i forespørselen. Dersom regelsettet ikke tillater dette, vil lisensforespørselen bli avvist i trinn 626, og en feilmelding vil bli returnert til API 306 i trinn 628.

I trinn 630 validerer den lisensutstedende entiteten

rettighetsspesifikasjonen 308. Den digitale signaturen av

rettighetsspesifikasjonen blir validert og, dersom den lisensutstedende entiteten ikke er utstederen av rettighetsspesifikasjonen (den entiteten som signerte den), bestemmer da den lisensutstedende entiteten hvorvidt utstederen av rettighetsspesifikasjonen er en annen pålitelig entitet ( f. eks. en entitet med hvilken den lisensutstedende entiteten tillates å dele nøkkelmateriale). Dersom rettighetsspesifikasjonen ikke er gyldig eller den ikke er utstedt av en pålitelig entitet, avvises da lisensforespørselen i trinn 626, og en feilmelding vil bli returnert til API 306 i trinn 628.

Etter at alle valideringer er utført oversetter den lisensutstedende entiteten rettighetsspesifikasjonen 308 til en lisens for hver av de godkjente lisensmottakerne. I trinn 632 genererer den lisensutstedende entiteten en respektiv rettighetsbeskrivelse for den lisensen som skal utstedes til hver lisensmottaker. For hver lisensmottaker evaluerer den utstedende entiteten den identiteten som er angitt i fellesnøkkel-sertifikatet til denne lisensmottakeren mot de identitetene som er angitt i rettighetsbeskrivelsen i rettighetsspesifikasjonen. Rettighetsbeskrivelsen overdrar til hver rettighet eller hvert sett av rettigheter et sett av identiteter som kan anvende denne rettigheten eller dette settet av rettigheter i en lisens. For hver rettighet eller hvert sett av rettigheter med hvilke denne lisensmottakerens identitet er assosiert, blir denne rettigheten eller dette settet av rettigheter kopiert inn i en ny datastruktur for lisensen. Den resulterende datastrukturen er rettighetsbeskrivelsen i lisensen for den spesifikke lisensmottakeren. Som del av denne prosessen evaluerer den lisensutstedende entiteten eventuelle betingelser som kan være assosiert med hvilke som helst av rettighetene eller settene av rettigheter i rettighetsbeskrivelsen i rettighetsspesifikasjonen. For eksempel kan en rettighet ha en tidsbetingelse assosiert med seg som hindrer den lisensutstedende entiteten i å utstede en lisens etter et spesifisert tidspunkt. I et slikt tilfelle vil den utstedende entiteten måtte sjekke den nåværende tiden, og dersom det tidspunktet som er spesifisert i betingelsen har vært, vil ikke den utstedende entiteten kunne utstede denne rettigheten til lisensmottakeren selv om denne lisensmottakerens identitet er assosiert med denne rettigheten.

I trinn 636 tar den utstedende entiteten (PU-DRM(DESI)) og (DES1(CK)) fra rettighetsspesifikasjonen 308 og anvender (PR-DRM) for å oppnå (CK). Den utstedende entiteten rekrypterer deretter (CK) ved anvendelse av (PU-ENTITY) lisensmottakerens fellesnøkkel-sertifikat, hvilket resulterer i (PU-ENTITY(CK)). I trinn 638 sammenkjeder den utstedende entiteten den genererte rettighetsbeskrivelsen med (PU-ENTITY(CK)), og signerer digitalt den resulterende datastrukturen ved anvendelse av (PR-DRM). Denne signerte datastrukturen er lisensen for denne spesifikke lisensmottakerentiteten.

Når, i trinn 640, den utstedende entiteten bestemmer at det ikke er flere lisenser å generere for den aktuelle forespørselen, vil den ha generert null eller flere lisenser. De genererte lisensene returneres til den forespørrende entiteten i trinn 642, sammen med sertifikatkjeden assosiert med disse lisensene { f. eks. serverens eget fellesnøkkel-sertifikat så vel som det sertifikatet som utstedte dennes sertifikat, og så videre).

I en foretrukket utførelsesform av et system ifølge oppfinnelsen kan det anvendes flere lisensgivernøkler. I en slik utførelsesform kan den innholdsnøkkelen (CK) som blir sendt kryptert gjennom rettighetsspesifikasjonen 308 og inn i lisensen være hvilke som helst vilkårlige data. Én spesielt nyttig variasjon er å anvende flere separate, krypterte innholdsnøkler (CK), henholdsvis assosiert med forskjellige rettigheter eller forskjellige aktører i rettighetsbeskrivelsen. For eksempel vil de digitale versjonene av sanger på et album alle kunne være kryptert med forskjellige nøkler (CK). Disse nøklene (CK) vil være inkludert i samme rettighetsspesifikasjon, men én aktør kan ha rettighet til å spille én av sangene { f. eks. kan han eller hun bare ha rettighet til å oppnå den ene nøkkelen i sin lisens), mens en andre aktør kan ha rettighet til å spille alle sangene (hun eller han vil da ha rettighet til å oppnå alle nøklene i sin lisens).

Et system ifølge oppfinnelsen gir fortrinnsvis publiserende applikasjoner/ brukere mulighet til å angi grupper eller klasser av lisensmottakere i en rettighetsspesifikasjon 308.1 en slik utførelsesform vil den lisensutstedende entiteten evaluere alle grupper / klasser som er angitt i rettighetsspesifikasjonen for å bestemme hvorvidt den nåværende lisensmottakerens identitet er medlem av disse gruppene / klassene. Dersom medlemsskap i en angitt gruppe / klasse blir funnet, kan den utstedende entiteten legge til de rettighetene eller det settet av rettigheter som er assosiert med gruppen / klassen i rettighetsbeskrivelse-datastrukturen som blir anvendt for lisensen.

I en foretrukket utførelsesform av oppfinnelsen støtter publiserings- og lisensierings-protokollgrensesnittene i DRM-serveren autentisering og autorisering av den kallende applikasjonen eller brukeren, og administrasjonskonsollen for DRM-serveren gir en administrator mulighet til å generere en tilgangskontrolliste for både lisensierings- og publiseringsgrensesnittet. Dette gjør at kjøperen av serveren kan anvende regelsett under hvilke brukere/applikasjoner enten gis tillatelse til å publisere, lisensiere eller begge deler.

Eksempel på plattform og dens relasjon til identiteter og lisenser

Den tillitsmodellen som foreliggende oppfinnelse støtter er basert på den tanke at beskyttelse av rettighetsforvaltet innhold er avhengig av beskyttelse av de nøklene som beskytter innholdet. Som beskrevet ovenfor blir innhold kryptert med en symmetrisk nøkkel CK som brukeren tilveiebringer. Siden den endelige konsumenten av innholdet trenger CK for å dekryptere innholdet, er ett problem som et DRM-system må løse hvordan å tilveiebringe denne nøkkelen til innholdskonsumenten på en sikker måte slik at nøkkelen ikke blir eksponert under transport og også slik at konsumenten ikke kan misbruke nøkkelen. Figurene 6-8 viser strukturer som kan anvendes for å tilveiebrunge nøkkelen CK til brukeren på en sikker måte. Figur 6 viser et eksempel på plattform 602 som tilveiebringer kryptografiske tjenester. Plattform 602 omfatter et fellesnøkkel/privatnøkkel-par PU-PLATFORM/PR-PLATFORM og en kryptografimodul 604 som anvender nøkkelparet for å utføre kryptografiske tjenester. Funksjonen til plattform 602 er å utføre disse kryptografiske tjenestene uten å avsløre den private plattformnøkkelen PR-PLATFORM. Et objekt som anvender plattform 602 fremsetter således kryptografi-forespørseler (f.eks. forespørseler om å dekryptere innhold, forespørseler om å verifisere digitale signaturer) og mottar kryptografi-resultater (f.eks. dekryptert innhold, signaturverifikasjoner). Fordi plattformen 602 tilveiebringer resultatene uten å avsløre den private plattformnøkkelen PR-PLATFORM til brukeren, blir plattformen 602 noen ganger kalt en "sort boks".

Plattform 602 kan ha forskjellige implementeringer, og en hvilken som helst av disse implementeringene kan anvendes i henhold til oppfinnelsen. For eksempel kan plattform 602 være en integritetssikret programvareenhet som inneholder den private plattformnøkkelen på en skjult form og anvender kodeobfuseringsteknikker for å komplisere forsøk fra en datasnok på å oppnå den private nøkkelen ved å analysere programvaren. Som et annet eksempel kan plattform 602 være en selvbærende integrert krets med en fysisk sperre som beskytter kretsen mot analyse og/eller forårsaker at kretsen ødelegger seg selv dersom sperren blir forsøkt brutt. Det er forventes at hver datamaskin på hvilken rettighetsforvaltet innhold kan bli anvendt vil ha én slik plattform med et unikt nøkkelpar. En hvilken som helst plattform som utfører de kryptografiske funksjonene beskrevet ovenfor kan anvendes i henhold til oppfinnelsen, uavhengig av de mekanismene som blir anvendt for å beskytte den private nøkkelen; hva slags mekanisme som blir anvendt for å beskytte den private nøkkelen påvirker imidlertid plattformens pålitelighet, som beskrevet nedenfor i forbindelse med figur 9.

Figur 7 viser et eksempel på identitetssertifikat 702. Identitetssertifikatet 702 definerer identiteten til en person. I dette tilfellet er personen john@microsoft.com; når john@microsoft.com ønsker å oppnå en lisens for rettighetsforvaltet innhold, er således identitetssertifikatet 702 den datastrukturen som john@microsoft.com anvender for å identifisere seg for den DRM-serveren som vil generere denne lisensen. Identitetssertifikatet 702 inneholder: et fellesnøkkel-sertifikat for fellesnøkkelen PU-ENTITY; den private nøkkelen PR-ENTITY kryptert med plattformens fellesnøkkel PU-PLATFORM; og den digitale signaturen til utstederen av identitetssertifikatet 702 (som er generert med den private nøkkelen til denne utstederen, PR-ISSUER).

Som beskrevet ovenfor i forbindelse med figurene 4, 5A og 5B, blir et sertifikat inneholdende PU-ENTITY sendt til DRM-serveren under en lisensforespørsel. Identitetssertifikatet 702 er et eksempel på et slikt sertifikat. PU-ENTITY er således den nøkkelen som blir anvendt for å kryptere innholdsnøkkelen CK i trinn 636 (vist i figur 5B). Ettersom identitetssertifikatet 702 vil bli installert på en brukers maskin, er det viktig at brukeren ikke har direkte tilgang til PR-ENTITY, siden enhver som besitter PR-ENTITY vil kunne dekryptere innholdsnøkkelen CK i en lisens og kompromittere beskyttelsen av innholdet. Identitetssertifikatet 702 lagrer således PR-ENTITY kryptert av PU-PLATFORM, slik at plattformen 602 kan dekryptere PR-ENTITY når det er nødvendig å oppnå CK fra en lisens. Ettersom enhver som er i besittelse av PR-ENTITY vil kunne stjele innholdet, representerer den digitale signaturen i identitetssertifikatet 702 sertifikatutstederens løfte om at PR-ENTITY er beskyttet og ikke har blitt distribuert til en ikke-klarert plattform.

Det skal bemerkes at identitetssertifikatet 702 støtter en dekopling av en brukers datamaskin fra brukerens identitet. Som følge av dette kan john@microsoft.com ha sin identitet installert på mange datamaskiner ganske enkelt ved å få sertifikatet regenerert for mange plattformer (selv om det kan være en identitetsplattform som begrenser antallet sertifikater som kan bli utstedt for samme identitet, eller typen plattform på hvilken slike sertifikater kan bli installert). Disse forskjellige sertifikatene ville være de samme, bortsett fra at fellesnøkkelen PU-PLATFORM som krypterer PR-ENTITY i sertifikatet ville være forskjellig fra plattform til plattform. I tillegg støtter identitetssertifikatet 702 generering av gruppe-identiteter. For eksempel kan avdelingen for bildeler i en bil-bedrift ha en identitet; dokumenter kan således bli lisensiert til og være konsumerbare for hele bildel-avdelingen ganske enkelt ved å få alle i bildel-avdelingen til å installere en instans av bildel-identitetssertifikatet på sine datamaskiner.

Figur 8 viser en lisens 802 som er utstedt til en identitet. Lisensen 802 omfatter: rettigheter (dvs. de regler som bestemmer hva som kan gjøres med innholdet og de omstendigheter under hvilke innholdet kan bli konsumert); innholdsnøkkelen CK kryptert med PU-ENTITY; og en signatur dannet med den private nøkkelen PR-DRM til den DRM-serveren som utstedte lisensen. Som kan sees i figur 8, kan CK bare gjenopprettes fra lisensen ved anvendelse av den private identitetsnøkkelen PR-ENTITY for å dekryptere PU-ENTITY(CK). I praksis må en således ha et identitetssertifikat 702 som inneholder PR-ENTITY for å anvende lisensen, siden dette er den eneste måten å gjenopprette CK fra lisensen. Videre, siden PR-ENTITY i identitetssertifikatet 702 er kryptert med plattformens fellesnøkkel PU-PLATFORM, må identitetssertifikatet være spesifikt generert for den plattformen 602 på hvilken innholdet vil bli konsumert. For å anvende lisensen for å konsumere innhold, må brukeren således ha en lisens som er utstedt til sin identitet og må ha et identitetssertifikat utstedt til den plattform på hvilken innholdet konsumeres.

Tillitsmodell

DRM-systemet beskrevet ovenfor beskytter innhold gjennom flere lag av nøkler. Disse lagene av nøkler representerer i sin tur en kjede av tillitsrelasjoner som leder fra innholdseieren til den plattformen på hvilken innholdet til slutt vil bli anvendt. Figur 9 viser relasjonen mellom de forskjellige nøklene og tillitskjeden som disse nøklene medfører.

Som vist i figur 9 er innhold 902 beskyttet med en innholdsnøkkel 904 (betegnet CK i den foregående diskusjonen). Innholdsnøkkelen 904, i sin tur, er beskyttet med et identitet-nøkkelpar 906 (PU-ENTITY/PR-ENTITY). Den private identitet-nøkkelen er i sin tur beskyttet av et plattform-nøkkelpar 908 (PU-PLATFORM, PR-PLATFORM). Som beskrevet ovenfor, er den private identitet-nøkkelen (PR-ENTITY) fortrinnsvis lagret på en dataanordning i et identitetssertifikat og kryptert med dataanordningens plattform-fellesnøkkel - dvs. som PU-PLATFORM(PR-ENTITY) - slik at PR-ENTITY bare kan dekrypteres med PR-PLATFORM.

En vil lett forstå at enhver svakhet i beskyttelseskjeden fra innholdet 902 til plattform-nøkkelparet 908 vil kompromittere sikkerheten til innholdet 902. Dersom innholdsnøkkelen 904 blir offentlig kjent, kan således da hvem som helst dekryptere innholdet 902. Likeledes, dersom den private identitet-nøkkelen blir offentlig kjent, kan da hvem som helst dekryptere innholdsnøkkelen 902 og deretter dekryptere innholdet 902. Til slutt, dersom den private plattformnøkkelen blir offentlig kjent, kan da hvem som helst dekryptere den private identitet-nøkkelen og således innholdsnøkkelen, og dermed innholdet. Følgelig avhenger sikkerheten ved det å gi tilgang til innhold gjennom disse krypteringslagene av at innholdsnøkkelen, den private identitet-nøkkelen og den private plattform-nøkkelen ikke blir kompromittert.

Følgelig blir muligheten for å holde hver av disse nøklene beskyttet etablert gjennom en tillitskjede, som er vist i elementene 912 til 918 i figur 9. Når innholdseieren 912 publiserer innholdet, genererer innholdseieren innholdnøkkelen CK og deler denne nøkkelen med lisensgiveren (dvs. DRM-serveren) når rettighetsspesifikasjonen blir presentert for signering. Ettersom innholdseieren ikke ønsker å gi fri tilgang til innholdet, stoler innholdseieren 912 således på at lisensgiveren 914 ikke kompromitterer innholdsnøkkelen - dvs. leverer ut innholdsnøkkelen bare under kontrollerte omstendigheter. Tilsvarende, når lisensgiveren utsteder en lisens til en gitt identitet (hvilket nødvendigvis involverer det å levere ut innholdsnøkkelen på en slik måte at den kan bli dekryptert ved anvendelse av den private identitetsnøkkelen), stoler lisensgiveren essensielt på at utstederen 916 av identitetssertifikatet har utstedt identitetssertifikatet på en slik måte at den private identitetsnøkkelen kan anvendes bare under legale, kontrollerte omstendigheter. I sin tur, når identitetssertifikat-utstederen 916 utsteder et identitetssertifikat til en gitt plattform 918 (og med det gjør at plattformen kan anvende den private identitetsnøkkelen, PR-ENTITY), stoler utstederen 916 på at plattformen 918 ikke vil misbruke den private nøkkelen.

Intet rettighetsforvaltningssystem er perfekt i det å beskytte innhold mot misbruk; ethvert rettighetsforvaltningssystem kan knekkes av en ondsinnet entitet med tilstrekkelig tid, kunnskaper, ressurser og motivasjon. Naturen til et rettighetsforvaltningssystem er imidlertid slik at en innholdseier 912 kan bestemme hvorvidt de forskjellige entiteter som er involvert i behandlingskjeden (f.eks. lisensgiver 914, identitetssertifikat-utsteder 916 og plattform 918 i dette eksemplet) vil beskytte sine respektive nøkler med tilstrekkelig habilitet og integritet til at innholdseieren kan stole på disse entitetene. Det kan lett forstås at innholdets sikkerhet således er direkte avhengig av hvilke entiteter en stoler på og hvilke entiteter en ikke stoler på.

Som beskrevet nedenfor tilveiebringer oppfinnelsen et system og en fremgangsmåte for å utstede innhold basert på etablering (eller avvisning) av spesifikke typer av tillitsrelasjoner.

Tillit mellom flere identitetsservere

Som angitt ovenfor kan et sikkerhetsskjema delvis defineres ved å bestemme hvem en skal stole på og hvem en ikke skal stole på. Ett aspekt ved disse tillitsavgjørelsene er at lisensgiveren bestemmer hvorvidt denne lisensgiveren har tillit til de identitetssertifikatene som er utstedt av en gitt utsteder av slike sertifikater. Denne tillitsavgjørelsen er viktig, ettersom lisensgiveren vil kryptere innholdsnøkkelen med fellesnøkkelen til dette identitetssertifikatet (PU-ENTITY), og alle således vil ha tilgang til det krypterte innholdet dersom det ikke tas forholdsregler for å hindre at den motsvarende private nøkkelen (PR-ENTITY) kommer i gale hender.

Figur 10 viser flere identitetsservere 1002(1) og 1002(2) som utsteder identitetssertifikater 1 og 2 (referansenummer 1004(1) og 1004(2)). I dette eksemplet er identitetssertifikatet 1 for entiteten "Joe", og identitetssertifikatet 2 er for entiteten "Fred". Slike identiteter kan noen ganger være referert til som "personer". Mens de viste eksemplene på personer er individer, vil det forstås fra den foregående beskrivelsen at et identitetssertifikat også kan definere en "gruppe-entitet" eller en "gruppe-person" (så som "bildel-avdelingen"). Hvert identitetssertifikat er assosiert med et (forholdsvis) unikt nøkkelpar og identitetssertifikatet selv inneholder fellesdelen av dette nøkkelparet. Identitetssertifikat 1 inneholder således fellesnøkkelen PU-JOE, og identitetssertifikat 2 inneholder fellesnøkkelen PU-FRED. (Som angitt ovenfor i forbindelse med figur 7 kan et identitetssertifikat også inneholde den private delen av nøkkelparet, selv om fortrinnsvis ikke ukryptert, siden brukeren ikke bør har fri tilgang til den private nøkkelen.) I tillegg omfatter hvert identitetssertifikat en signatur. Signaturen er tatt over (i hvert fall) fellesnøkkelen. Hvert sertifikat omfatter signaturen til sin utsteder. Identitetssertifikatet 1 er således signert av den private nøkkelen til identitetsserver 1 (PR-IS1), og identitetssertifikat 2 er signert av den private nøkkelen til identitetsserver 2 (PR-IS2). Når identitetsserverne 1 og 2 signerer disse identitetssertifikatene, hevder de essensielt at de vil beskytte de private nøklene for disse identitetssertifikatene mot å bli kompromittert.

Noen identitetsservere kan være bedre (eller dårligere) til å sikre sikkerheten til de private nøklene for de entiteter de genererer. I eksempelet i figur 10 har identitetsserver 1 "strenge sikkerhetsprosedyrer," og identitetsserver 2 har "slakke sikkerhetsprosedyrer". Det relative sikkerhetsnivået mellom disse prosedyrene vil kunne ta en hvilken som helst form. For eksempel installerer muligens identitetsserver 1 den private nøkkelen kun på anordninger som er kjent å ha fysisk sikrede plattformnøkler, mens identitetsserver 2 kan levere ut den private nøkkelen i klartekst uten å verifisere påliteligheten til mottakeren av denne nøkkelen, og/eller uten å verifisere typen plattform på hvilken den private nøkkelen vil bli installert. Disse er noen eksempler på hvorledes forskjellige identitetsservere kan avvike med hensyn til den relative effektiviteten i sine sikkerhetsprosedyrer.

Som følge av disse forskjellene i sikkerhet mellom identitetsservere, kan en DRM-server bestemme at noen identitetsservere er pålitelige og at noen ikke er det. En DRM-server kan således utstede en lisens kun til de identitetssertifikater som er signert av identitetsservere som DRM-serveren stoler på. I eksempelet i figur 10 stoler DRM-server 320 på identitetsserver 1, men stoler ikke på identitetsserver 2, siden server 1 har strenge sikkerhetsprosedyrer mens server 2 har slakke sikkerhetsprosedyrer. Følgelig vil DRM-server 320 utstede lisenser bare for de identitetssertifikater som er signert med den private nøkkelen til identitetsserver 1.

Det skal bemerkes at selv om figur 10 viser server 1 og server 2 henholdsvis med "strenge" og "slakke" sikkerhetsprosedyrer, den selektive tilliten til identitetsservere ikke trenger å være basert på "slakk" versus "streng". For eksempel kan serverne 1 og 2 ganske enkelt ha forskjellige mekanismer med hensyn til sikkerhet, autentisering, etc, selv om det ikke kategorisk kan sies at én server sine sikkerhetsmekanismer er "strengere" enn den andres. DRM-server 320 har like fullt rett til å foreta et valg vedrørende hvilke identitetsservere den vil stole på og hvilke den ikke vil stole på. For eksempel kan to systemer begge ha sterke sikkerhetsprosedyrer, men kan autentisere brukeren på forskjellig måte - f.eks. kan ett system kreve et smartkort og et annet system kreve et X509-sertifikat - og denne forskjellen kan være viktig for den entiteten som opererer DRM-server 320. Selv om det må forstås at det å velge å stole på en identitetsserver basert på styrken til dens sikkerhet kan være en typisk anvendelse av oppfinnelsen, er dette således bare én av mange mulige grunner til hvorfor DRM-server 320 kan velge å stole på noen identitetsservere men ikke andre.

Figur 11 viser et eksempel der avgjørelsen av hvilken eller hvilke identitetservere som kan stoles på påvirker måten med hvilken to organsasjoner kan dele dokumenter. To bedifter - "Bedrift A" og "Bedrift B" - ønsker at deres ansatte skal kunne dele dokumenter, og tilgang til disse dokumentene er kontrollert av et DRM-system. Bedrift A sine ansatte har identiteter som er utstedt av bedrift A sin identitetsserver 1102, og bedrift B sine ansatte har identiteter som er utstedt av bedrift B sin identitetsserver 1104.1 tillegg har hver bedrift sin egen DRM-server som utsteder lisenser for å se DRM-kontrollerte dokumenter. Typisk vil bedrift A sin DRM-server 1106 være innrettet for å stole på bedrift A sin identitetsserver 1102, og bedrift B sin DRM-server 1104 være innrettet for å stole på bedrift B sin identitetsserver 1108.

I et typisk scenario vil en ansatt i bedrift A presentere en signert rettighetsspesifikasjon for bedrift A sin DRM-server 1106 for å oppnå en lisens for et stykke innhold. Den ansatte har en identitet (dvs. et identitetssertifikat, med et nøkkelpar PU-ENTITY/PR-ENTITY) som er utstedt av bedrift A sin identitetsserver 1102. Antatt at den signerte rettighetsspesifikasjonen tillater at en lisens blir utstedt til denne ansatte, vil da bedrift A sin DRM-server 1106 være i stand til å generere en lisens for den ansattes identitetssertifikat, ettersom bedrift A sin DRM-server 1106 stoler på bedrift A sin identitetserver 1102. Anta imidlertid at en ansatt i bedrift A publiserer et stykke innhold og ønsker å gi en ansatt i bedrift B tillatelse til å anvende dokumentet. Når bedrift A sin ansatte skaper en rettighetsspesifikasjon for innholdet, kan denne rettighetsspesifikasjonen angi personalia for en ansatt i bedrift B som én av de tillatte lisensmottakere for innholdet. Dersom den ansatte i bedrift B kontakter bedrift A sin DRM-server 1106 for å oppnå en lisens, vil imidlertid ikke bedrift A sin DRM-server 1106 være i stand til å utstede en lisens for denne ansattes identitetssertifikat, siden bedrift B sine ansatte har identitetssertifikater som er utstedt av bedrift B sin identitetsserver 1104, og bedrift A sin DRM-server 1106 ikke (enda) stoler på bedrift B sin identitetsserver 1104. (Som beskrevet nedenfor i forbindelse med figurene 13-14, vil det være mulig å tillate bedrift B sin DRM-server å utstede lisenser for innhold som har blitt publisert ved bedrift A, selv om det å gjøre dette krever at bedrift A og bedrift B deler sine private nøkler, hvilket kan være uønsket i noen tilfeller.)

Løsningen er å etablere en tillitsrelasjon mellom bedrift A sin DRM-server 1106 og bedrift B sin identitetsserver 1104. Fortrinnsvis tar bedrift A skritt for å forsikre seg om at bedrift B sin identitetsserver 1104 tar passende sikkerhetsforanstaltninger når den utsteder identiteter. Antatt at bedrift A blir overbevist om at bedrift B sin identitetsserver møter dens sikkerhetsstandarder, kan da bedrift A sin DRM-server 1106 stole på bedrift B sin identitetsserver 1104. Denne tillitsrelasjonen gjør at bedrift A sine ansatte kan publisere dokumenter som kan bli lisensiert til bedrift B sine ansatte. Tilsvarende kan bedrift B sin DRM-server 1108 stole på bedrift A sin identitetsserver 1102, og derved tillate bedrift B sine ansatte å publisere dokumenter som kan bli lisensiert til bedrift A.

Tillitsrelasjoner kan etableres ved at hver DRM-server opprettholder en pålitelig-identitetsserver-liste 1110 og 1112. Hver identitetsserver har et nøkkelpar, og hver identitetsserver kan identifiseres av felles-andelen av sitt nøkkelpar. Bedrift A sin identitetsserver har nøkkelparet PU-A/PR-A, og bedrift B sin identitetsserver har nøkkelparet PU-B/PR-B. Hvert identitetssertifikat inneholder fortrinnsvis fellesnøkkel-sertifikatet til den identitetsserveren som utstedte sertifikatet; gitt et identitetssertifikat kan således en DRM-server bestemme hvorvidt den stoler på den identitetsserveren som har utstedt identitetssertifikatet ved å sammenlikne identitetsserverens fellesnøkkel som er angitt i identitetssertifikatet med fellesnøklene på listen av pålitelige identitetsservere. (En identitetsserver kan også har en separat identifikator som den inkluderer i de identitetssertifikatene som den utsteder. DRM-serveren kan bestemme hvilken identitetsserver som har utstedt identitetssertifikatet basert på fellesnøkkelen, identifikatoren eller begge deler.) Listen over pålitelige identitetsservere kan refereres til som et "pålitelige-personer-domene".

Bedrift A kan således tillate sine ansatte å publisere innhold for bedrift B sine ansatte ved å legge til bedrift B sin identitetsserver i bedrift A sin tillitsliste (antatt at bedrift B sine ansatte har identitetssertifikater som er utstedt av bedrift B sin identitetsserver). Likeledes kan bedrift B kan legge til bedrift A sin identitetsserver i sin tillitsliste. Figur 11 viser fellesnøkkelen PU-B lagt til i bedrift A sin tillitsliste 1110, og fellesnøkkelen PU-A lagt til i bedrift B sin tillitsliste 1112.

Ekskludering av visse sertifikater utstedt av ellers pålitelige identitetsservere

Som angitt ovenfor kan en DRM-server selektivt stole på/ikke stole på visse identitetsservere. Én forbedring som er verdt å merke seg for denne modellen for selektiv tillit/mistillit vedrører utelukking av gitte identiteter fra den generelle tilliten til en gitt identitetsserver. For eksempel kan en DRM-server generelt stole på en gitt identitetsserver, men ikke ønske å utstede lisenser til visse sertifikater som er registrert til gitte epost-adresser, domener, etc. Ett eksempel på dette - selv om det ikke er eneste eksempel - er tilfellet med identitetsservere som utsteder identiteter til offentligheten basert på epost-adresser; MICROSOFT .NET PASSPORT er et eksempel på en slik identitetsserver.

Figur 12 viser identitetsservere 1202 og 1204. Identitetsserver 1202 kan for eksempel være en offentlig epostadresse-basert identitetsserver som utsteder identitetssertifikater basert på en epost-adresse og et pass tilveiebragt av en bruker. For eksempel kan en bruker ha forhåndsregistrert en epost-adresse (f.eks. xxx@hotmail.com) og et passord; identitetsserver 1202 kan ganske enkelt be brukeren om epost-adressen og passordet og utstede et identitetssertifikat dersom brukeren entrer den korrekte kombinasjonen epost-adresse/passord - uten å kreve noen mer rigorøs autentisering av brukeren. Den offentlige, epostadresse-baserte identitetsserveren 1202 kan også ha den sikkerhetsmessige ulempen at den, i noen tilfeller, kan installere et identitetssertifikat på en hvilken som helst plattform brukeren forespør uten hensyn til sikkerhetsevnen til denne plattformen. Denne teknikken kan betraktes en relativt usikker metode for å utstede identitetssertifikater.

I motsetning har identitetsserveren 1204 høy sikkerhet. Identitetsserveren 1204 krever en forholdsvis streng sjekk før den utsteder et identitetssertifikat. For eksempel kan en bruker måtte presentere seg personlig (med sin datamaskin) for en systemadministrator (i form av et menneske) som forårsaker at serveren 1204 installerer et identitetssertifikat på brukerens datamaskin dersom han eller hun er overbevist om at datamaskinen er tilstrekkelig sikker og at brukeren har rett til en slik identitet. Brukeren kan måtte autentisere seg ved anvendelse av fingeravtrykk, et smartkort, etc. Alternativt, dersom serveren 1204 er identitetsserveren for en bedrift, kan brukeren måtte aksessere serveren 1204 via bedriftens intranett, heller enn via Internett. Det kan således sees at høysikkerhet-serveren 1204 er forholdsvis mer sikker enn den epostadresse-baserte serveren 1202.

I eksempelet i figur 12 oppnår plattform 1 (referansenummer 1206) et identitetssertifikat fra den epost-baserte identitetsserveren, og plattform 2 (referansenummer 1208) oppnår et identitetssertifikat fra høysikkerhet-identitetsserveren. Som angitt ovenfor kan utstederen av disse sertifikatene bestemmes fra sertifikatet selv, siden hvert identitetssertifikat omfatter fellesnøkkel-sertifikatet til dets utsteder og er signert av utstederens private nøkkel. (I eksempelet i figur 12 har den offentlige, epostadresse-baserte serveren 1202 nøkkelenparet PU-IS1/PR-IS1, og høysikkerhet-identitetsserveren 1204 har nøkkelparet PU-IS2/PR-IS2). Når plattformene 1 og 2 forsøker å oppnå lisenser for et innhold ved å sende lisensforespørseler 1210 (omfattende deres respektive identitetssertifikater) til DRM-server 320, kan DRM-serveren således bestemme hviken identitetsserver som har utstedt identitetssertifikatet og således bestemme hvorvidt den stoler på den identitetsserveren som utstedte identitetssertifikatet. Som angitt ovenfor tar DRM-serveren 320 denne avgjørelsen ved å sjekke sin liste over pålitelige identitetsservere. Figur 12 viser to alternative eksempler på liste 1212 og 1214.

(Det forventes ikke at DRM-server 320 vil anvende to tillitslister samtidig; disse listene er snarere begge vist i figur 12 som alternative eksempler på lister som DRM-serveren 320 vil kunne anvende.)

I det første eksempelet der listen 1212 blir anvendt, stoler DRM-server 320 på høysikkerhet-identitetsserveren 1204 (fordi denne serverens fellesnøkkel-sertifikat (PU-IS2) finnes i tillitslisten 1212), men DRM-server 320 stoler ikke på den epostadresse-baserte serveren 1202 under noen omstendigheter.

I det andre eksempelet der listen 1214 blir anvendt, stoler DRM-serveren 320 på høysikkerhet-identitetsserveren 1204, og stoler også på den epostadresse-baserte identitetsserveren 1202 med noen unntak. I den eksempelvise listen 1214 ekskluderer tilliten til den offentlige epost-baserte identitetsserveren 1202 sertifikater utstedt til en gitt identitet

(joe@untraceableaddress.com) eller et gitt domenenavn (alle addresser som har domenenavnet high-security.com). For eksempel kan

joe@untraceableaddress.com være en person som er kjent som en innholdstyv (f.eks. en misfornøyd tidligere ansatt i den bedriften som drifter DRM-serveren 320), så DRM-serveren 320 stoler ikke på ham. Grunnen til at en vil kunne ønske å ekskludere et helt domenenavn er noe kontra-intuitiv: Anta at høysikkerhet-serveren 1204 er en bedrift-identitetsserver og at den utsteder identiteter for ansatte på formen xxx@high-security.com. Mens bedriften stoler på sine egne ansatte, kan den ønske å stole på dem bare dersom de faktisk anvender identitetssertifikater oppnådd fra bedriftens identitetsserver 1204 (som følge av denne serverens sterkere autentiseringsprosedyrer eller evne til å påtvinge bedriftsregler). Bedriften kan anta at enhver ansatt som ønsker å identifisere seg gjennom (slakkere sikkerhet) serveren 1202 kan forsøke å omgå en eller annen regel som gjelder ved bedriften. Det å legge inn high-security.com på ekskluderingslisten sikrer at personer som kan oppnå identiteter gjennom høysikkerhet-serveren 1204 vil gjøre dette, mens det også tillater andre personer å autentisere seg ved anvendelse av den epostadresse-baserte serveren 1202.

Mens figur 12 og den foregående diskusjonen beskriver anvendelse av en ekskluderingsliste for en offentlig epost-basert identitetsserver, må det forstås at konseptet med en ekskluderingsliste kan anvendes med en hvilken som helst identitetsserver. For eksempel kan bedrift 1 sin DRM-server stole på identiteter som er utstedt av bedrift 2 sin identitetsserver, men bedrift 1 kan ønske å tvinge sine egne ansatte til å oppnå identiteter gjennom sin egen server. Bedrift 1 sin DRM-server kan således opprettholde en ekskluderingsliste for bedrift 2 sin identitetsserver, slik at ethvert sertifikat som er utstedt av bedrift 2 sin identitetsserver, men som angir en epost-adresse på formen xxx@company1 . com er ekskludert fra denne tilliten (antatt at bedrift 1 sine ansatte har epost-adresse i domenet companyl .com).

Utstedelse av en lisens basert på en annen server sin rettighetsspesifikasjon

Som beskrevet ovenfor oppnå en bruker generelt en lisens fra den samme DRM-serveren som signerte den rettighetsspesifikasjonen på hvilken lisensen er basert. Én grunn til dette er at lisensen må omfatte innholdsnøkkelen (CK), men innholdsnøkkelen er lagret i lisensen kryptert av DRM-serverens fellesnøkkel, PU-DRM. Kun den DRM-serveren som besitter den tilhørende private nøkkelen, PR-DRM, kan således oppnå nøkkelen CK for å generere lisensen. (I én utførelsesform blir det anvendt en symmetrisk nøkkel DES1, slik at den signerte rettighetsspesifikasjonen inneholder: DES1(CK) og PU-DRM(DESI). Effekten er imidlertid den samme; CK kan bare oppnås av en identitet som er i besittelse av PR-DRM.) Noen ganger er det imidlertid ønskelig at én DRM-server kan utstede en lisens for et stykke innhold som har blitt publisert av en annen DRM-server.

Én måte for å muliggjøre slik "krysslisensiering" av innhold er at en første server (den serveren som publiserte innholdet) tilveiebringer sin private nøkkel til en annen server (den serveren som vil lisensiere innholdet). En må være forsiktig ved deling av den private nøkkelen. En DRM-servers pålitelighet er tilveiebringes av dens private nøkkel, og hvem som helst som har den private nøkkelen kan "personifisere" denne DRM-serveren (dvs. ved å signere rettighetsspesifikasjoner og utstede lisenser). Den første DRM-serverens private nøkkel må således bare bli delt med den andre DRM-serveren dersom det kan fastslås at den andre DRM-serveren ikke vil kompromittere den private nøkkelen. Videre utføres transporten av den private nøkkelen fortrinnsvis på en sikker måte, slik at nøkkelen ikke vil bli avslørt for uønskede under transport.

Figur 13 viser et eksempel med to DRM-servere, og hvorledes én DRM-server kan anvendes for å utstede en lisens basert på en rettighetsspesifikasjon som er utstedt av den andre DRM-serveren. DRM-server 1 (referansenummer 1320) har et nøkkelpar PU-DRM1/PR-DRM1, og DRM-server 2 (referansenummer 1322) har et nøkkelpar PU-DRM2/PR-DRM2. En bruker 1302 har et kryptert innhold 1304 og en signert rettighetsspesifikasjon 1306 for dette innholdet. Bruker 1302 ønsker å oppnå en lisens for dette innholdet. Den signerte rettighetsspesifikasjonen omfatter en kryptert utgave av innholdsnøkkelen CK, slik at det kun er mulig å oppnå CK ved anvendelse av PR-DRM 1 for å dekryptere den symmetriske nøkkelen DES1 og deretter anvende DES1 på DES1(CK) for å oppnå CK; uten PR-DRM1 er det med andre ord ikke mulig å oppnå CK for å utstede en lisens for innholdet 1304. Når brukeren 1302 sender den signerte rettighetsspesifikasjonen 1306 til DRM-server 2, vil denne DRM-serveren således ikke være i stand til å utstede en lisens for innholdet 1306.

Dersom imidlertid DRM-server 1 deler sin private nøkkel PR-DRM 1 med DRM-server 2 (som representert ved den stiplede linjen som forbinder DRM-server 1 og DRM-server 2), vil da DRM-server 2 kunne anvende denne private nøkkelen for å oppnå CK og utstede en lisens. Figur 13 viser ett eksempel på fremgangsmåte for å transportere PR-DRM1 fra DRM-server 1 til DRM-server 2.1 eksempelet i figur 13 er PR-DRM 1 kryptert med fellesnøkkelen til DRM-server 2, hvilket gir PU-DRM2(PR-DRM1). PR-DRM1 er således beskyttet mot alminnelig tilgjengelighet, og PR-DRM1 kan gjenopprettes ved å dekryptere PU-DRM2(PR-DRM1) med DRM-server 2 sin private nøkkel PR-DRM2. Det må forstås at det finnes andre sikre måter for å transportere en privat nøkkel, og måten vist i figur 13 er kun et eksempel. Som et annet eksempel kan den private nøkkelen bli lagret på en disk og transportert av et pålitelig bud. Det settet av private nøkler som en DRM-server har tilgang til definerer denne serverens "pålitelig-dokument-domene". Figur 14 viser et eksempel der denne typen "krysslisensieringsskjema" kan være nyttig. Bedrift 1400 er spredt geografisk over forskjellige steder. Avdeling A 1402 befinner seg i Winslow, Arizona, mens avdeling B 1404 befinner seg i Asbury Park, New Jersey. Av praktiske grunner, drifter hver avdeling sin egen DRM-server, henholdsvis 1406 og 1408. Foreksempel kan disse avdelingene anvende DRM-serveren for å publisere og/eller lisensiere tusenvis av dokumenter hver dag, og det vil kunne være umulig å avhenge av å transportere data gjennom hele landet for å utføre alle disse publiserings-og/eller lisensieringsoperasjonene. Ettersom avdelingene A og B tilhører samme bedrift 1400, kan det imidlertid være at ansatte ved avdeling A vil publisere innhold som kan være lisensiert til ansatte i avdeling B, og vise versa. Brukerne 1410 og 1412, henholdsvis ved avdelingene A og B, har således begge innhold som er publisert av DRM-server A og innhold som er publisert av DRM-server B. For eksempel kan bruker 1412 sende til bruker 1410 innhold som er publisert på DRM-server B, og bruker 1410 kan sende til bruker 1412 innhold som er publisert på DRM-server A.

Uansett hvilken server som ble anvendt for å publisere innholdet, kontakter hver bruker serveren ved sin egen avdeling for å oppnå en lisens. Bruker 1410 ber derfor om lisenser fra avdeling A sin DRM-server 1406, og bruker 1412 ber om lisenser fra avdeling B sin server 1408. Hver server kan utstede lisenser for ethvert innhold som har blitt publisert av denne serveren, siden rettighetsspesifikasjonen for dette innholdet er generert med denne serverens fellesnøkkel. I tillegg kan hver server utstede lisenser for innhold som har blitt publisert av den andre serveren, så lenge serverne har delt sine respektive private nøkler, PR-DRMA og PR-DRMB.

Prosessen med å validere tillit for lisensforespørseler

Figur 15 viser et eksempel på prosess som en DRM-server utfører for å validere tillit for en innkommende lisensforespørsel. Prosessen omfatter de følgende konsepter: (1) identitetssertifikatet må være utstedt av en pålitelig identitetsserver; (2) dersom identitetssertifikatet er utstedt av en offentlig, epostadresse-basert identitetsserver, må ikke personen (f.eks. joe@untraceableaddress.com) eller domenet (f.eks. high-security.com) angitt i sertifikatet finnes på en ekskluderingsliste; og (3) rettighetsspesifikasjonen må være utstedt av en server som den lisensierende DRM-serveren har en relasjon til.

Etter at en DRM-server mottar en innkommende lisensforespørsel (som fortrinnsvis omfatter en signert rettighetsspesifikasjon og et identitetssertifikat), bestemmer DRM-serveren hvorvidt identitetssertifikatet finnes i et "pålitelige-personer-domene" - dvs. hvorvidt identitetssertifikatet er utstedt av en pålitelig identitetsserver (trinn 1502). Dersom identitetssertifikatet ikke er i pålitelige-personer-domenet, blir lisensforespørselen avvist på grunn av tillitsfeil (trinn 1512). Dersom identitetssertifikatet finnes i et pålitelige-personer-domene, fortsetter prosessen til trinn 1504.

I trinn 1504 bestemmer DRM-serveren hvorvidt det finnes en gjeldende ekskluderingsliste for den pålitelige identitetsserveren som utstedte identitetssertifikatet. Ett eksempel som er nevnt ovenfor er der utstederen av identitetssertifikatet er en offentlig epostadresse-basert identitetsserver, så som en MICROSOFT .NET PASSPORT-server, og der DRM-serveren har valgt å behandle identitetssertifikater som er utstedt av denne serveren forskjellig dersom disse identitetssertifikatene er utstedt til visse epost-adresser og/eller domener. Det må imidlertid forstås at en ekskluderingsliste kan være satt opp for en hvilken som helst identitetsserver i pålitelige-personer-domenet; trinn 1504 omfatter således generelt bestemmelse av hvorvidt det eksisterer en ekskluderingsliste assosiert med en gitt pålitelig identitetsserver.

Dersom det ikke finnes en ekskluderingsliste assosiert med den identitetsserveren som utstedte identitetssertifikatet, fortsetter prosessen til trinn 1508. Dersom det imidlertid finnes en slik ekskluderingsliste, bestemmer da DRM-serveren (trinn 1506) hvorvidt identitetssertifikatet skal ekskluderes (dvs. hvorvidt en lisens dette sertifikatet skal nektes) basert på de personalia for hvilke dette sertifikatet er utstedt (f.eks. basert på epost-adressen, domenet eller en annen identifikator som er spesifisert i identitetssertifikatet). Dersom identitetssertifikatet må ekskluderes av en slik grunn, blir deretter lisensforespørselen avvist på grunn av en tillitsfeil (trinn 1512). På den annen side, dersom ekskluderingslisten ikke spesifiserer at identitetssertifikatet skal ekskluderes, fortsetter prosessen til trinn 1508.

I trinn 1508 bestemmer DRM-serveren hvorvidt den signerte rettighetsspesifikasjonen tilveiebragt i lisensforespørselen er utstedt av en DRM-server i den lisensierende DRM-serverens "pålitelig-dokument-domene". Som beskrevet ovenfor omfatter dette "pålitelig-dokument-domenet": (a) den DRM-serveren som prosesserer lisensforespørselen; og (b) andre DRM-servere som har tilveiebragt sine private nøkler til den DRM-serveren som prosesserer forespørselen (og at den lisensierende DRM-serveren fortsetter å ha tillit). Dersom den DRM-serveren som utstedte den signerte rettighetsspesifikasjonen ikke finnes i pålitelig-dokument-domenet, blir da lisensforespørselen avvist som følge av en tillitsfeil (trinn 1512). Dersom, på den annen side, den signerte rettighetsspesifikasjon er utstedt av en server i pålitelig-dokument-domenet, er da tillitsforespørselen validert, og lisensforespørselen blir prosessert (trinn 1510).

Den endelige utstedelsen av lisensen kan skje i henhold til prosessen beskrevet ovenfor i figurene 5A-5B. Videre kan prosessen beskrevet i figur 15 være supplerende til prosessen beskrevet i figurene 5A-5B, og disse to prosessene kan være flettet sammen. Spesifikt er trinnene 1502, 1504 og 1506 essensielt måter for å autentisere og autorisere forespørrerens identitet (som vist i figur 5A, trinnene 604 og 606), og trinn 1508 er essensielt en spesifikk måte for å validere den signerte rettighetsspesifikasjonen (som vist i figur 5B, trinn 630).

Konklusjon

Den programmeringen som er nødvendig for å realisere fremgangsmåtene som utføres i forbindelse med foreliggende oppfinnelse er relativt enkel, og skulle være åpenbar for den relevante programmerer. Følgelig er ikke slik programming innlemmet her. En hvilken som helst spesifikk programmering kan derfor anvendes for å realisere foreliggende oppfinnelse innenfor dennes idé og ramme.

Videre vil fagmannen forstå at en rekke endringer og modifikasjoner kan foretas av de foretrukne utførelsesformene av foreliggende oppfinnelse, og at en kan foreta slike endringer og modifikasjoner uten å fjerne seg fra oppfinnelsens idé. Intensjonen er derfor at de etterfølgende patentkravene skal dekke alle slike ekvivalente variasjoner som faller innenfor oppfinnelsen sanne idé og ramme.

Claims (19)

1. Fremgangsmåte for lisensiering av innhold, omfattende de trinn å: motta en forespørsel (1210) for en lisens, idet lisensforespørselen omfatter et identitetsssertifikat (1004) for en entitet til hvilken lisensen skal utstedes og identitetssertifikatet angir en utsteder (1002) av sertifikatet i sertifikatet; og bestemme om utstederen av identitetssertifikatet (1004) er pålitelig; bestemme at betingelsene for å lisensiere innholdet til entiteten er til stede; generere lisensen for den entiteten som skal anvende innholdet; og sende lisensen til entiteten;karakterisert vedhvor bestemmelsen om at utstederen av identitetssertifikatet (1004) er pålitelig omfatter: å bestemme om utstederen utsteder identitetssertifikater til offentligheten basert på e-postadresser og passord, idet sertifikatet angir en e-postadresse; å bestemme at hverken e-postadressen eller domenenavnet som identifiseres av e-postadressen, finnes på en ekskluderingsliste.

2. Fremgangsmåte ifølge krav 1, der identitetssertifikatet (1004) inneholder: (a) et fellesnøkkel-sertifikat assosiert med utstederen; og (b) en digital signatur for utstederen, og der fremgangsmåten videre omfatter det å anvende fellesnøkkel-sertifikatet for å verifisere den digitale signaturen.

3. Fremgangsmåte ifølge krav 1, der lisensforespørselen omfatter rettighetsdata som angir lisensieringsbetingel-ser under hvilke en lisens kan utstedes, og der trinnet med å bestemme at betingelsene for å lisensiere innholdet er til stede, baseres på rettighetsdataene.

4. Fremgangsmåte ifølge krav 1, der identitetssertifikatet omfatter en fellesnøkkel og enten omfatter eller er assosiert med en privat nøkkel som svarer til fellesnøkkelen, og der det trinn å generere en lisens omfatter det å: kryptere en dekrypteringsnøkkel for innholdet med fellesnøkkelen for å generere en kryptert dekrypteringsnøkkel; og inkludere den krypterte dekrypteringsnøkkelen i lisensen.

5. Fremgangsmåte ifølge krav 1, der identitetssertifikatet omfatter en fellesnøkkel og enten omfatter eller er assosiert med en privat nøkkel som svarer til fellesnøkkelen, og der det trinn å generere en lisens omfatter det å: kryptere en dekrypteringsnøkkel for innholdet med en symmetrisk nøkkel for å generere en kryptert dekrypteringsnøkkel; kryptere den symmetriske nøkkelen med fellesnøkkelen for å generere en kryptert symmetrisk nøkkel; og inkludere både den krypterte symmetriske nøkkelen og den krypterte dekrypteringsnøkkelen i lisensen.

6. Fremgangsmåte ifølge krav 1, der fremgangsmåten utføres av en server som opprettholder en liste av pålitelige utstedere, og der det trinn å bestemme at utstederen av identitetssertifikatet er pålitelig, omfatter det å bestemme hvorvidt utstederen finnes på listen.

7. Fremgangsmåte ifølge krav 6, der hver av de pålitelige utstederne har et tilhørende fellesnøkkel-sertifikat, der listen omfatter en liste over fellesnøkkel-sertifikatene for de pålitelige utstederne, og der fremgangsmåten omfatter det trinn å: bestemme hvorvidt utstederens fellesnøkkel-sertifikat finnes på listen.

8. Fremgangsmåte ifølge krav 1, videre omfattende de trinn å: bestemme at det finnes en gjeldende ekskluderingsliste for utstederen; og bestemme at identitetssertifikatet ikke er ekskludert ifølge betingelsene i ekskluderingslisten.

9. Fremgangsmåte ifølge krav 8, der ekskluderingslisten omfatter én eller flere epost-adresser, slik at en lisens ikke kan utstedes til noe identitetssertifikat som er utstedt av utstederen og som angir en epost-adresse som finnes på ekskluderingslisten, og der fremgangsmåten omfatter det trinn å bestemme at identitetssertifikatet ikke angir en epost-adresse som finnes på ekskluderingslisten.

10. Fremgangsmåte ifølge krav 8, der ekskluderingslisten omfatter ett eller flere domennavn, slik at en lisens ikke kan utstedes for noe identitetssertifikat som er utstedt av utstederen og som angir et domenenavn som finnes på ekskluderingslisten, og der fremgangsmåten omfatter det trinn å bestemme at identitetssertifikatet ikke angir et domenenavn som finnes på ekskluderingslisten.

11. Fremgangsmåte ifølge krav 8, der ekskluderingslisten omfatter én eller flere identifikatorer, slik at en lisens ikke kan utstedes for noe identitetssertifikat som er utstedt av utstederen og som inneholder en identifikator som finnes på ekskluderingslisten, og der fremgangsmåten omfatter det trinn å bestemme at identitetssertifikatet ikke inneholder en identifikator som finnes på ekskluderingslisten.

12. Datamaskinlesbart medium som inneholder datamaskin-eksekverbare instruksjoner for å utføre fremgangsmåten ifølge krav 1.

13. System for lisensiering av innhold omfattende: en liste av pålitelige entiteter; en lisensutstedermodul som mottar en lisensforespørsel omfattende et identitetssertifikat for en identitet som en lisens skal bli utstedt til, som bestemmer hvorvidt identitetssertifikatet er utstedt av en av de pålitelige entitetene, som bestemmer hvorvidt betingelsene for lisensiering av innholdet er oppfylt, og som utsteder en lisens dersom identitetssertifikatet er utstedt av en av de pålitelige entitetene og dersom betingelsene for lisensiering av innholdet er oppfylt;karakterisert ved at bestemmelsen om at utstederen av identitetssertifikatet (1004) er pålitelig omfatter: å bestemme om utstederen utsteder identitetssertifikater til offentligheten basert på epostadresser og passord, idet sertifikatet angir en epost-adresse; å bestemme at hverken epostadressen eller domenenavnet som identifiseres av epost-adressen, finnes på en ekskluderingsliste.

14. System ifølge krav 13, der hver av de pålitelige entitetene har et assosiert fellesnøkkel/privatnøkkel-par og et fellesnøkkel-sertifikat for felles-andelen av fellesnøkkel/privatnøkkel-paret, og der listen av pålitelige entiteter omfatter fellesnøkkel-sertifikatet for hver av de pålitelige entitetene.

15. System ifølge krav 13, der identitetssertifikatet omfatter en digital signatur for den av de pålitelige entitetene som utstedte identitetssertifikatet, og der lisensutstedermodulen anvender ett av fellesnøkkel-sertifikatene på listen for å verifisere den digitale signaturen.

16. System ifølge krav 13, der identitetssertifikatet omfatter fellesnøkkel-sertifikatet for den av de pålitelige entitetene som utstedte identitetssertifikatet, og der lisensutstedermodulen bestemmer hvorvidt identitetssertifikatet er utstedt av en pålitelig entitet ved å sammenlikne fellesnøkkel-sertifikatet i identitetssertifikatet med fellesnøkkel-sertifikatene på listen.

17. System ifølge krav 13, der hver av de pålitelige entitetene har en assosiert identifikator, og der listen av pålitelige entiteter omfatter identifikatoren for hver av de pålitelige entitetene.

18. System ifølge krav 16, der identitetssertifikatet omfatter identifikatoren for den av de pålitelige entitetene som utstedte identitetssertifikatet, og der lisensutstedermodulen bestemmer hvorvidt identitetssertifikatet er utstedt av en pålitelig entitet ved å sammenlikne identifikatoren i identitetssertifikatet med identifikatorene på listen.

19. System ifølge krav 17, der hver av de pålitelige entitetene har et assosiert fellesnøkkel/privatnøkkel-par og et fellesnøkkel-sertifikat for felles-andelen av fellesnøkkel/privatnøkkel-paret, der listen av pålitelige entiteter omfatter fellesnøkkel-sertifikatet for hver av de pålitelige entitetene, der identitetssertifikatet videre omfatter fellesnøkkel-sertifikatet for den av de pålitelige entitetene som utstedte identitetssertifikatet, og der lisensutstedermodulen videre bestemmer hvorvidt identitetssertifikatet er utstedt av en pålitelig entitet, ved å sammenlikne fellesnøkkel-sertifikatet i identitetssertifikatet med fellesnøkkel-sertifikatene på listen.