NO334468B1 - Fremgangsmåte og anordning for å tilveiebringe en sikker maskinvareidentifikator til bruk i forbindelse med et forvaltningssystem for digitale rettigheter - Google Patents

Abstract

En betrodd komponent i en innretning innbefatter en sikker HWID (maskin- vareidentifikator) og blir verifisert ved å fremskaffe en nøkkel fra Innretningen og verifisere hver signert komponent i operativsystemet til innretningen med denne. En drivertabell blir undersøkt for å lokalisere en HWID-drlver som blir verifisert til å inneholde en peker tilbake til en adresse i en kjerne. Det verifiserte operativsystem blir anropt for å fremskaffe den sikre HWID fra en HWID-komponent ved hjelp av HWID-drlveren og for å returnere denne til den betrodde komponent. Deretter blir den returnerte HWID verifisert som i overensstemmelse med den HWID som er innbefattet i den betrodde komponent.

Description

TEKNISK OMRÅDE

Foreliggende oppfinnelse vedrører et system slik som et forvaltningssystem for digitale rettigheter (DRM-system) for å håndheve rettigheter til digitalt innhold. Mer spesielt vedrører foreliggende oppfinnelse et slikt håndhevelsessystem som bare gir tilgang til kryptert digitalt innhold i forbindelse med parametere som er spesifisert ved hjelp av lisensrettigheter innhentet av en bruker av det digitale innhold. Enda mer spesielt angår foreliggende oppfinnelse frembringelse av en innretning med en sikker maskinvareidentifikator (HWID) for bruk i et slikt håndhevelsessystem, hvorved systemet kan bindes til vedkommende HWID.

BAKGRUNN FOR OPPFINNELSEN

Som kjent, og det vises nå til fig. 1, er forvaltningssystemer for digitale rettigheter (DRM, digital rights management) og håndhevelsessystemer meget øns-kelig i forbindelse med digitalt innhold 12, slik som digital audio, digital video, digital tekst, digitale data, digitale multimedia, osv., hvor slikt digitalt innhold 12 skal distribueres til brukere. Ved mottakelse av brukeren gjengir eller avspiller brukeren det digitale innhold ved hjelp av en passende gjengivelsesanordning, slik som en mediaspiller på en personlig datamaskin 14 eller lignende.

En innholdseier som distribuerer slikt digitalt innhold 12, ønsker vanligvis å begrense hva brukeren kan gjøre med dette distribuerte digitale innhold 12. Innholdseieren kan f.eks. ønske å hindre brukeren fra å kopiere og redistribuere slikt innhold 12 til en annen bruker, eller kan ønske å tillate distribuert digitalt innhold 12 å bli spilt bare et begrenset antall ganger, bare i en viss total tid, bare på en viss type maskin, bare på en viss type mediaspiller, bare av en viss type bruker, osv.

Etter at distribusjon har inntruffet har imidlertid innholdseieren meget liten, om noen, kontroll over det digitale innhold 12. Et DRM-system 10 tillater da den kontrollerte gjengivelse eller avspilling av vilkårlige former for digitalt innhold 12, hvor denne kontrollen er fleksibel og kan defineres av innholdseieren av dette digitale innhold. Innhold 12 blir vanligvis distribuert til brukeren i form av en pakke 13 ved hjelp av en passende distribusjonskanal. Den digitale innholdspakke 12 som distribueres, kan innbefatte det digitale innhold 12 kryptert med en symmetrisk krypterings/dekrypterings-nøkkel (KD), (f.eks. (KD(CONTENT))), så vel som annen informasjon som identifiserer innholdet, hvordan en lisens for dette innholdet skal skaffes, osv.

Det tillitsbaserte DRM-system 10 gjør det mulig for en eier av digitalt innhold 12 å spesifisere lisensregler som må tilfredsstilles før dette digitale innholdet 12 blir tillatt gjengitt på en brukers datainnretning 14. Slike lisensregler kan innbefatte de forannevnte tidsmessige begrensninger, og kan være innbakt i en digital lisens 16 som brukeren/brukerens datainnretning 14 (heretter blir disse uttrykkene brukt om hverandre med mindre annet er nødvendig) må fremskaffe fra innholdseieren eller en av dennes agenter. Denne lisensen 16 innbefatter også dekrypter-ingsnøkkelen (KD) for dekryptering av det digitale innhold, eventuelt kryptert i innhold til en nøkkel som kan dekrypteres av brukerens datainnretning.

Innholdseieren av et stykke digitalt innhold 12 må stole på at brukerens datainnretning 14 vil holde seg til reglene og kravene som er spesifisert av innholdseieren i lisensen 16, dvs. at det digitale innhold 12 ikke vil bli gjengitt med mindre reglene og kravene i lisensen 16 er tilfredsstilt. Brukerens datainnretning 14 er fortrinnsvis forsynt med en betrodd komponent eller mekanisme 18 som ikke vil gjengi det digitale innhold 12 uten i henhold til lisensreglene som er innbakt i lisensen 16 i forbindelse med det digitale innhold 12 og fremskaffet av brukeren.

Den betrodde komponent 16 har typisk en lisensevaluator 20 som bestemmer om lisensen 16 er gyldig, bedømmer lisensreglene og kravene i en slik gyldig lisens 16, og bestemmer, basert på de bedømte lisensregler og krav, om den anmodede bruker har rett til å gjengi det anmodede digitale innhold 12 på den søkte måte, blant andre ting. Som man vil forstå er lisensevaluatoren 20 betrodd i DRM-systemet 10 til å utføre ønskene til eieren av det digitale innhold 12 i henhold til de regler og krav som befinner seg i lisensen 16, og brukeren bør ikke lett være i stand til å endre et slikt betrodd element for noe formål, uhederlig eller på annen måte.

Som man vil forstå, kan reglene og kravene i lisensen 16 spesifisere om brukeren har rett til å gjengi det digitale innhold 12 basert på noen av flere fakto-rer, innbefattende hvem eieren er, hvor brukeren befinner seg, hvilken type bereg-ningsinnretning som brukeren benytter, hvilken gjengivelsesapplikasjon som anroper DRM-systemet, dataoen, tiden, osv. Reglene og kravene i lisensen 16 kan vid ere begrense lisensen 16 til et forutbestemt antall avspillinger eller f.eks. en forutbestemt spilletid.

Reglene og kravene kan være spesifisert i lisensen 16 i henhold til et hvilket som helst passende språk og en hvilken som helst passende syntaks. Språket kan f.eks. ganske enkelt spesifisere attributter og verdier som må være tilfredsstilt (dato (DATE) må senere enn X, f.eks.), eller kan ganske enkelt kreve utførelse av funksjoner i henhold til et spesifisert skript (IF DATE greater than X, THEN DO ..., f.eks.).

Når lisensevaluatoren 20 bestemmer at lisensen 16 er gyldig og at brukeren tilfredsstiller reglene og kravene i denne, blir dekrypteringsnøkkelen (KD) fremskaffet fra lisensen 12 og blir anvendt på (KD(CONTENT)) fra innholdspakken 13 for å resultere i det aktuelle innhold 12, og det aktuelle innhold 12 blir så faktisk gjengitt.

I et DRM-system 10, blir innhold pakket for anvendelse av en bruker ved å kryptere dette innholdet 12 og tilknytte en lisens 16 med et sett regler, til innholdet 12, slik at innholdet 12 kan gjengis bare i samsvar med reglene i lisensen 16. For-di innholdet 12 krever lisensen 16 for tilgang til innholdet, så kan innholdet 12 fritt distribueres. Det er viktig at lisensen 16 på en eller annen måte blir knyttet enten direkte eller indirekte til en datainnretning 14 på hvilken innholdet 12 skal gjengis. Ellers kan innholdet 12 potensielt kopieres til et uendelig antall andre innretninger 14 og gjengis på disse også.

Det å binde en lisens 16 til en innretning 14 er kjent eller bør være opplagt for det relevante publikum og behøver derfor ikke å angis mer detaljert her. Hvis den er direkte bundet til innretningen, kan lisensen 16 innbefatte en identifikator for innretningen 14 i lisensen, og kan kreve bekreftelse på at innretningen 14 virkelig er den innretning 14 som er identifisert i lisensen. Hvis den er direkte bundet til innretningen, kan lisensen 16 innbefatte en kryptert dekrypteringsnøkkel som bare kan dekodes ved hjelp av en maskinvare eller programvare som befinner seg på innretningen 14 (dvs. den betrodde komponent 18), idet denne kan innbefatte identifikatoren for innretningen 14, og lisensen 16 og/eller komponenten kan kreve bekreftelse på at innretningen 14 virkelig er den innretning 14 som er identifisert i komponenten.

Lisensen 16 er typisk knyttet til en datainnretning 14 ved hjelp av en unik maskinvareidentifikator (HWID, hardware identifier) som befinner seg i innretningen 14 og som ikke lett kan overføres til noen annen innretning 14. En slik HWID kan være en fysisk HWID som er permanent innsatt i innretningen 14 og som kan fremskaffes elektronisk fra innretningen 14, eller kan beregnes fra et antall verdier som er elektronisk tilstede i innretningen 14, slik som f.eks. et serienummer for en fastplatestasjon, et serienummer for et internminne, et serienummer for en proses-sor, osv. Beregning av en HWID basert på verdier innebygd i innretningen 14, og disse verdiene er datamaskinlesbare og antas å være pålitelige nok ut fra et mask-invaresynspunkt til at en forbrytersk entitet ikke kan endre eller misbruke verdiene i et forsøk på å undergrave DRM-systemet 10. Det vil si at maskinvaren i innretningen 14 må antas å være pålitelig nok til å hindre endring eller misbruk av verdiene.

Det kan imidlertid hende at det i virkeligheten ikke kan antas at verdiene i en innretning 14 virkelig er pålitelige slik at en HWID basert på slike verdier kan betraktes som sikre. Det vil si at det kan hende at maskinvaren i innretningen 14 ikke er i stand til å beskytte verdiene på en pålitelig måte. Maskinvaren har f.eks. kanskje ikke riktige verdier, eller maskinvaren kan ha riktige verdier, men ikke på en datamaskinlesbar og sikker form, eller maskinvaren kan manipuleres for å avgi en ukorrekt verdi blant annet. Slik ikke pålitelig maskinvare og slike ikke pålitelige verdier kan spesielt være tilstede i en forholdsvis enkel innretning 14, slik som f.eks. en bærbar musikkspiller eller en bærbar dataassistent. Som man vil forstå, kan det i slike enkle innretninger 14 være meget lite maskinvare å snakke om, og denne maskinvaren innbefatter kanskje ikke datamaskinlesbare identifikatorer som er i stand til å virke som identifiseringsverdier, maskinvaren er kanskje ikke i stand til å kommunisere en identifikator til operativsystemet og/eller innretningen 14 og maskinvaren på denne eller kanskje ikke den funksjonalitet som er nødvendig for å skjule slike verdier, blant annet. Selvsagt kan det også hende at andre mer kom-plekse innretninger 14 også ikke har den pålitelige maskinvare og de pålitelige verdier som er nødvendig for bibringe sikker HWID til innretningen 14.

Det er derfor et behov for en fremgangsmåte og en mekanisme for å bibringe en sikker HWID til en innretning 14 i det tilfelle hvor maskinvaren ikke kan betros å tilveiebringe en sikker HWID. Spesielt finnes det et behov for en fremgangsmåte og en mekanisme som gjør det mulig for en fabrikant av innretningen 14 å bibringe en sikker HWID til en innretning 14 som kan fremskaffes av opera tivsystemet til innretningen 14. Enda mer spesielt finnes det et behov for programvare på en programvare 14 som er levert av fabrikanten, og som kan betros å bibringe en sikker HWID til innretningen 14 og åpenbare denne sikre HWID for operativsystemet i en slik innretning 14, hvor den sikre HWID ikke lett kan endres eller misbrukes av en forbrytersk entitet.

OPPSUMMERING AV OPPFINNELSEN

De forannevnte behov blir tilfredsstilt i det minste delvis ved hjelp av foreliggende oppfinnelse, hvor en datainnretning er fremstilt for å sikre at innretningen kan aksessere en sikker maskinvareidentifikator (HWID) på denne. Datainnretnin-gen er innrettet for å motta en del med digitalt innhold og en digital lisens for denne, og for å gjengi innholdet i samsvar med lisensen, og lisensen er knyttet til den sikre HWID slik at lisensen ikke er operativ på en annen innretning som har en annen sikker HWID.

Oppfinnelsen tilveiebringer i et første aspekt en fremgangsmåte som angitt i det selvstendige krav 1. Oppfinnelsen tilveiebringer i et andre aspekt en datainnretning som angitt i det selvstendige krav 8. Foretrukkede utførelsesformer av oppfinnelsen er angitt i henholdsvis de uselvstendige kravene 2-7 og 9-13.

En offentlig nøkkel (PU-OEM) blir mottatt fra en sertifiseringsautoritet med en signatur fra den sertifiserende autoritet, og (PU-OEM) med signaturen blir plassert i et internminne i innretningen. Et operativsystem for innretningen blir mottatt, hvor operativsystemet har flere individuelle komponenter, innbefattende en utfør-bar kjerne, et antall drivere og en drivertabell med en peker til hver driver. Hver av minst noen av de individuelle komponenter er fulgt av en signatur basert på komponenten.

Innretningen blir levert med en HWID-komponent for å fremskaffe den sikre HWID fra innretningen og videresende den sikre HWID til operativsystemet i innretningen når operativsystemet ber om dette, og en HWID-driver er plassert i internminnet som et tillegg til operativsystemet. HWID-driveren kommuniserer med HWID-komponenten for å fremskaffe og videresende den sikre HWID.

En referanse til HWID-driveren er plassert i drivertabellen, og for hver signert komponent i operativsystemet, blir signaturen til komponenten verifisert og fjernet. Komponenten blir så signert med en hemmelig nøkkel (PR-OEM) som sva- rer til (PU-OEM). Alle komponentene i operativsystemet, innbefattende komponentene med (PR-OEM)-signaturen, blir så anbrakt i internminnet.

En betrodd komponent blir fremskaffet for innretningen fra en betrodd kom-ponentautoritet, og blir konstruert for å innbefatte den sikre HWID på en sikker måte. Den betrodde komponent blir verifisert ved å fremskaffe (PU-OEM) med dennes signatur og verifisering av signaturen. Hver signert komponent av operativsystemet blir også verifisert ved å verifisere dennes signatur basert på den fremskaffede (PU-OEM), drivertabellen blir undersøkt for å lokalisere HWID-driveren, og HWID-driveren blir verifisert som å inneholde en peker tilbake til en adresse i kjernen.

Hvis HWID-driveren og operativsystemet verifiseres, blir operativsystemet anropt for å fremskaffe den sikre HWID fra HWID-komponenten og returnere denne til den betrodde komponent. Kjernen mottar anropet og omdirigerer dette til HWID-driveren ved hjelp av drivertabellen, og HWID-driveren fremskaffer den sikre HWID ved hjelp av HWID-komponenten og tilbakesender denne til den betrodde komponent. Deretter blir det verifisert at den returnerte HWID stemmer overens med den HWID som er innbefattet i den betrodde komponent.

KORT BESKRIVELSE AV TEGNINGENE

Den foregående oppsummering samt den følgende detaljerte beskrivelse av utførelsesformene av foreliggende oppfinnelse, vil kunne forstås bedre lest i sam-menheng med de vedføyde tegninger. For det formål å illustrere oppfinnelsen, er det på tegningene vist utførelsesformer som for tiden blir foretrukket.

Som man vil forstå, er oppfinnelsen imidlertid ikke begrenset til de nøyak-tige arrangementer og komponenter som er vist. Det vises så til tegningene, hvor: fig. 1 er et blokkskjema som viser en håndhevelsesarkitektur som et eksem-pel på et system basert på tiltro;

fig. 2 er et blokkskjema som representerer et generelt datasystem hvor asp-ekter ved foreliggende oppfinnelse og/eller deler av denne kan inkorporeres;

fig. 3 er et blokkskjema som viser en datainnretning med en betrodd komponent, et operativsystem og en maskinvareidentifikator (HWID)-komponent for å fremskaffe en sikker HWID for innretningen i samsvar med en utførelsesform av foreliggende oppfinnelse;

fig. 4 og 4A er flytskjemaer som viser nøkkeltrinn utført ved anbringelse av den betrodde komponent, operativsystemet og maskinvareidentifikator (HWID)-komponenten på innretningen i fig. 3, i samsvar med en utførelsesform av foreliggende oppfinnelse;

fig. 5 er et blokkskjema over et ROM-bilde frembrakt i forbindelse med trin-nene på 4 og 4A; og

fig. 6 er et flytskjema som viser de nøkkeltrinn som utføres av den betrodde komponent på fig. 3 nå det gjelder å fremskaffe den sikre HWID for innretningen på fig. 3, i samsvar med en utførelsesform av foreliggende oppfinnelse.

DETALJERT BESKRIVELSE AV OPPFINNELSEN DATAMILJØ

Fig. 1 og den følgende diskusjon er ment å gi en kort, generell beskrivelse av et egnet datamiljø hvor foreliggende oppfinnelse og/eller deler av denne kan implementeres. Selv om det ikke er nødvendig, er oppfinnelsen beskrevet i den generelle forbindelse med datamaskinutførbare instruksjoner, slik som programmoduler som utføres av en datamaskin, slik som en klientarbeidsstasjon eller en server. Generelt innbefatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer og lignende som utfører spesielle oppgaver eller imple-menterer spesielle abstrakte datatyper. Dessuten skal det bemerkes at oppfinnelsen og/eller deler av denne kan praktiseres med andre datasystemutforminger, innbefattende håndholdte innretninger, multiprosessor-systemer, mikroprosessor-basert- eller programmerbar forbrukerelektronikk, nettilknyttede PCer, minidata-maskiner, stormaskiner og lignende. Oppfinnelsen kan også praktiseres i distribuerte datamiljøer hvor oppgaver blir utført av fjerntliggende behandlingsinnret-ninger og som er sammenknyttet gjennom et kommunikasjonsnett. I et distribuert datamiljø kan programmoduler være anbrakt i både lokale og fjerntliggende min-nelagringsinnretninger.

Som vist på fig. 2 innbefatter et universelt datasystem en konvensjonell personlig datamaskin 120 eller lignende, innbefattende en prosesseringsenhet 121, et systemminne 122 og en systembuss 123 som kopler sammen forskjellige systemkomponenter, innbefattende systemminne til prosesseringsenheten 121. Systembussen 123 kan være en hvilken som helst av flere typer buss-strukturer, innbefattende en minnebuss eller en minnestyringsenhet, en periferibuss og en lokalbuss ved å benytte hvilken som helst av en rekke bussarkitekturer. System-minnet innbefatter et leselager (ROM) 124 og et direktelager (RAM) 125. Et grunnleggende inn/ut-system 126 (BIOS) som innholder de grunnleggende rutiner som bidrar til å overføre informasjon mellom elementer i den personlige datamaskin 120, slik som under start, er lagret i ROM 124.

Den personlige datamaskinen 120 kan videre innbefatte en harddisk-stasjon 127 for å lese fra og skrive til en harddisk (ikke vist), en magnetplate-stasjon 128 for å lese fra eller skrive til en fjernbar magnetisk plate 129 og en optisk plate-stasjon 130 for å lese fra eller skrive til en fjernbar optisk plate 131, slik som en CD-ROM eller andre optiske media. Harddisk-stasjonen 127, den magnetiske platestasjonen 128 og den optiske platestasjonen 130 er koplet til systembussen 123 ved hjelp av et harddisk-stasjonsgrensesnitt 132, et magnetisk platestasjonsgren-sesnitt 133 og et optisk stasjonsgrensesnitt 134. Stasjonene og deres tilhørende datamaskinlesbare media tilveiebringer ikke-flyktig lagring av datamaskinlesbare instruksjoner, datastrukturer, programmoduler og andre data for den personlige datamaskinen 20.

Selv om det miljøeksempelet som er beskrevet her, anvender en harddisk, en fjernbar magnetisk plate 129 og en fjernbar optisk plate 131, vil man forstå at andre typer datamaskinlesbare media som kan lagre data som er aksesserbare ved hjelp av en datamaskin, også kan brukes i eksempelet på driftsmiljø. Slike andre typer media innbefatter en magnetisk kassett, et flash-minnekort, en digital videoplate, en Bernoulli-modul, et direktelager (RAM), et leselager (ROM) og lignende.

Et antall programmoduler kan være lagret på harddisken, den magnetiske platen 129, den optiske platen 131, ROM 124 eller RAM 125, innbefattende et operativsystem 135, ett eller flere brukerprogrammer 136, andre programmoduler 137 og programdata 138. En bruker kan innføre kommandoer og informasjon i den personlige datamaskin 120 gjennom innmatingsinnretninger slik som et tastatur 140 og en pekerinnretning 142. Andre innmatingsinnretninger (ikke vist) kan innbefatte en mikrofon, en styrespak, en spillekonsoll, en satellittantenne, en skanner eller lignende. Disse og andre innmatingsinnretninger er ofte forbundet med prosesseringsenheten 121 gjennom et serieport-grensesnitt 146 som er koplet til systembussen, men kan være tilkoplet ved hjelp av andre grensesnittanordninger, slik som en parallellport, en spilleport eller en universell seriebuss (USB). En monitor 147 eller en visningsanordning av en annen type er også koplet til systembussen 123 via et grensesnitt, slik som en videoadapter 148. I tillegg til monitoren 147 innbefatter en personlig datamaskin vanligvis andre perifere utmatingsinnretninger (ikke vist), slik som høyttalere og skrivere. Eksempelet på et system ifølge krav 2 innbefatter også en vertsadapter 155, en liten datasystemgrensesnitt-buss (SCSI, Small Computer System Interface) 156, og en ekstern lagringsinnretning 162 koplet til SCSI-bussen 156.

Den personlige datamaskin 120 kan operere i et nettmiljø som benytter logiske forbindelser til én eller flere fjerntliggende datamaskiner, slik som en fjerntliggende datamaskin 149. Den fjerntliggende datamaskin 149 kan være en annen personlig datamaskin, en server, en ruter, en nett-PC, en likeverdig (peer) innretning eller en annen felles nettnode, og innbefatter typisk mange eller alle de elementer som er beskrevet ovenfor i forbindelse med den personlige datamaskin 120, selv om bare en minnelagringsanordning 150 er blitt illustrert på fig. 2. De logiske forbindelser som er skissert på fig. 2, innbefatter et lokalnett (LAN) 151 og et region-nett (WAN) 152. Slike nettmiljøer er vanlige på kontorer, i selskapsomfattende da-tanett, intranett og internett. Den personlige datamaskin 120 kan også virke som en vert for en gjest, slik som en annen personlig datamaskin 120, en mer spesiali-sert innretning, slik som en bærbar spiller eller en bærbar dataassistent, eller lignende, slik at verten laster ned data til og/eller laster opp data fra gjesten, blant annet.

Brukt i et LAN-nettmiljø er den personlige datamaskin 120 koplet til LAN 151 gjennom et nettgrensesnitt eller en adapter 153. Brukt i et WAN-nettmiljø innbefatter den personlige datamaskin 120 typisk et modem 154 eller en annen an-ordning for å opprette kommunikasjoner over regionnettet 152, slik som internett. Modemet 154 som kan være internt eller eksternt, er koplet til systembussen 123 via serieport-grensesnittanordningen 146. I et nettmiljø kan programmoduler skissert i forhold til den personlige datamaskin 120, eller deler av slike, være lagret i den fjerntliggende minnelagringsinnretning. Man vil forstå at nettforbindelsene som er vist, er eksempler og at andre anordninger for å opprette en kommunikasjons-forbindelse mellom datamaskinene kan brukes.

SIKKER MASKINVAREIDENTIFIKATOR (HWID)

En sikker HWID individualiserer en innretning 14 og gjør det mulig for en betrodd komponent 14 på innretningen 14 å verifisere at den virkelig er ment for

innretningen 14. Det vil si at den sikre HWID blir anvendt for å knytte den betrodde komponent 14 til innretningen 12, og en lisens 16 bundet til den betrodde komponent 14 blir ved utvidelse bundet til innretningen 14 og autoriserer innhold 12 som skal gjengis på innretningen 14. Innholdet 12 kan følgelig gjengis sikkert på en innretning 14 med et ikke-sikkert operativsystem. I noen innretninger 14 kan imidlertid operativsystemet til innretningen 14 ikke selv innhente en sikker HWID fra innretningen 14 basert på én eller flere verdier som befinner seg i innretningen 14.

I henhold til en utførelsesform av foreliggende oppfinnelse, og det vises nå til fig. 3, blir følgelig innretningen 14 fremstilt av en fabrikant som leverer innretningen 14 med en HWID-komponent 30 som innhenter en sikker HWID fra innretningen 14 og videresender denne sikre HWID til operativsystemet 32 for innretningen 14 når dette operativsystemet 32 ber om det. Det forutsettes at den sikre HWID er nødvendig, enten som en del for å binde en lisens 16 til innretningen 14 eller for å verifisere at en lisens 16 virkelig er bundet til innretningen 14, selv om den sikre HWID kan være nødvendig for andre formål uten å avvike fra rammen for foreliggende oppfinnelse.

HWID-komponenten 30 kan være en hvilken som helst passende komponent uten å avvike fra foreliggende oppfinnelses ramme. HWID-komponenten 30 kan f.eks. være en programvaredel eller kan være maskinvare. I tillegg kan HWID-komponenten 30 inneholde den sikre HWID eller kan fremskaffe den sikre HWID fra andre steder uten å avvike fra foreliggende oppfinnelses ramme. Den sikre HWID kan f.eks. befinne seg i HWID-komponenten 30 eller kan befinne seg langt fra denne, men kan fremskaffes ved hjelp av denne. Den sikre HWID kan være lagret på et hvilket som helst passende sted uten å avvike fra foreliggende oppfinnelses ramme. Den sikre HWID kan f.eks. være fysisk lagret i en maskinvaredel eller kan bare være en del av en programvaredel. Generelt er sikker lagring av HWID og anvendelse av HWID-komponenten 30 til sikkert for å fremskaffe HWID, kjent eller bør være opplagt for det relevante publikum og trenger derfor ikke å bli beskrevet mer detaljert her. Det er spesielt viktig at fabrikanten kan implementere den sikre HWID på en hvilken som helst måte uten å avvike fra foreliggende opp finnelses ramme, så lenge den implementerte HWID virkelig er sikker, og ikke lett kan endres eller misbrukes av en forbrytersk entitet.

I henhold til en utførelsesform av foreliggende oppfinnelse er HWID-komponenten 30 registrert i operativsystemet 32, og blir oppkalt av dette når en applika-sjon 34 ber om den sikre HWID. Som en del av sikringen av HWID og for å bibringe denne med troverdighet, blir både den fabrikantleverte HWID-komponent 30 og hver oppkalt komponent i operativsystemet 32 digitalt signert for å frembringe respektive digitale signaturer, og slike signaturer blir verifisert som en del av an-ropsprosessen for å sikre at komponentene ikke er blitt tuklet med eller byttet ut.

I henhold til en utførelsesform av foreliggende oppfinnelse befinner operativsystemet 32 seg, eller i det minste en relevant del av dette, på innretningen 14 i et ROM (leselager) 34 på innretningen og eksemplifiseres fra denne, og operativsystemet 32 er anbrakt på ROM'en 34 eller på befaling av fabrikanten av innretningen 14 i henhold til en fremgangsmåte ifølge foreliggende oppfinnelse for å sikre at operativsystemet 32 kan aksessere en sikker HWID ved hjelp av HWID-komponenten 30. Det vises til fig. 3 hvor en slik fremgangsmåte er som følger: Innledningsvis genererer fabrikanten eller en agent for denne (heretter kalt "fabrikanten" et asynkront, offentlig/hemmelig fabrikantnøkkelpar (PU-OEM, PR-OEM) (trinn 401), og leverer (PU-OEM) til en DRM-server (ikke vist) (trinn 403). Som man vil forstå, er DRM-serveren en sentral autoritet som sertifiserer at fabrikanten virkelig kan innbefatte innretningen 14 i DRM-systemet 10, og tilkjennegir sertifiseringen ved å returnere (PU-OEM) til fabrikanten signert med en hemmelig nøkkel for DRM-serveren (PR-PRM) for å resultere i ((PU-OEM) S (PR-DRM)). Fabrikanten mottar ((PU-OEM) S (PR-DRM)) (trinn 405) og anbringer dette i et ROM-bilde 36, som vist på fig. 5 (trinn 407).

Fabrikanten mottar typisk det aktuelle operativsystem 32 fra en ekstern kilde (trinn 409) og inkorporerer dette i innretningen 14. I henhold til en utførelses-form av foreliggende oppfinnelse, omfatter det mottatte operativsystem 32 flere individuelle filer, og hver relevant fil for operativsystemet 32 blir fulgt av en signatur basert på filen. Som man vil forstå, kan hver relevant fil omfatte hver eneste fil, eller kan være et valgt delsett av hver fil, slik som utførbare filer, utførbare filer relevant for DRM-prosessene, aller filer som er relevante for DRM-prosessene, kombinasjoner av dette og lignende.

Som man kan se på fig. 3, er én av filene i operativsystemet 32 en utførbar kjernefil 38. Som man vil forstå, tilveiebringer kjernen 38 i operativsystemet 32 kjernefunksjonaliteter. Kjernen 38 initialiserer typisk en funksjon ved å anrope en driver i operativsystemet 32 for å utføre funksjonen, og kjernen 38 har tilgang til en drivertabell 40 som innbefatter en peker til hver driver. Mest relevant for foreliggende oppfinnelse er at operativsystemet 32 på innretningen 14 innbefatter en HWID-driver 42 som kommuniserer med HWID-komponenten 30 for å fremskaffe den sikre HWID. Legg merke til at HWID-driveren 42 er spesifikk for HWID-komponenten 30, idet HWID-komponenten 30 er tilveiebrakt av fabrikanten og HWID-driveren 42 derfor også er tilveiebrakt av fabrikanten. Spesielt leverer fabrikanten HWID-driveren 42 ved å anbringe denne i ROM-bildet 36 (trinn 411), og anbringer en referanse til HWID-driveren 42 i drivertabellen 40 (trinn 413). Fabrikanten kan også signere HWID-driveren 42 med (PR-OEM) og anbringe signaturen i ROM-bildet 36 (trinn 414).

Fabrikanten tar også filene i operativsystemet 32 slik de er levert, og plas-serer disse filene i ROM-bildet 36 (trinn 415) for hver signert fil, og det vises nå til fig. 4A, hvor fabrikanten verifiserer dennes signatur (trinn 415A), hente ut signaturen (trinn 415B), lager en ny signatur for denne med (PR-OEM) (trinn 415 C), og anbringer filen i den nye signatur i ROM-bildet 36 (trinn 415D). I henhold til en ut-førelsesform av foreliggende oppfinnelse er hver signatur basert, ikke bare på filen, men på grunnadressen og lengden til filen i ROM-bildet 36 for å resultere i ((fil, start, lengde) S (PR-OEM)).

Med operativsystemet 32 som utført i ROM-bildet 36, som vist på fig. 5, og eventuelt med annen informasjon, anbringer fabrikanten dette operativsystemet 32 på innretningen 14 ved å brenne (ROM-bildet 36 inn i ROM 34 på en slik innretning 14 (trinn 417). I tillegg tilveiebringer fabrikanten en betrodd komponent 18 for innretningen 14 fra en DRM-betrodd komponentserver (ikke vist). Som man vil forstå, er den betrodde DRM-komponentserver en sentral autoritet som frembringer betrodde komponenter 18 og sikrer at hver betrodd komponent 18 er bundet til en innretning 14.

Spesielt aksesserer fabrikanten den sikre HWID fra innretningen 14 (trinn 419), og leverer den aksesserte HWID til serveren som en del av en anmodning om en betrodd komponent 18 for innretningen 14 (trinn 421). Serveren konstruerer den betrodde komponent 18 slik at den innbefatter den leverte HWID, og også slik at den innbefatter et offentlig/hemmelig nøkkelpar som skal tilknyttes innretningen 14 (PU-HW, PR-HW). Som man vil forstå, er HWID og (PR-HW) innbakt i den betrodde komponent 18 på en meget sikker måte slik at disse dataelementene ikke kan endres uten store vanskeligheter, men kan finnes av den betrodde komponent 18 selv. Fabrikanten mottar så den betrodde komponent 18 med (HWID, (PU-HWD), og (PR-HW), og anbringer den mottatte betrodde komponent 18 i et internlager 44 i innretningen (trinn 423). Legg merke til at den betrodde komponent 18 kan oppdateres fra tid til annen, i hvilket tilfelle internlageret 44 er et ikke-flyktig omskrivbart internlager 44. Den betrodde komponent 18 bør selvsagt beskyttes mot endring av en forbrytersk entitet, og bør derfor i det minste innbefatte en veri-fiseringssignatur, og eventuelt andre sikkerhetsforanstaltninger. Legg merke til at i en alternativ utførelsesform av oppfinnelsen, fremskaffer en sluttbruker av innretningen 14 den betrodde komponent 18 for denne.

Med den sikre HWID, HWID-komponenten 30, operativsystemet 32 i ROM 34 og den betrodde komponent i internlageret 44, aksesserer innretningen 14 under bruk den sikre HWID ved å verifisere operativsystemet 32 og så foreta et anrop til HWID-driveren 42 for å fremskaffe den sikre HWID fra HWID-komponenten 30. Igjen er den sikre HWID forutsetningsvis enten nødvendig som en del for å binde en lisens 16 til innretningen 14 eller for å verifisere at lisens 16 i virkeligheten er bundet til innretningen 14, selv om den sikre HWID kan være nødvendig for hvilke som helst andre formål uten å avvike fra foreliggende oppfinnelses ramme. Som man vil forstå, bibringer verifisering av operativsystemet 32 tillit til HWID-driveren 42, og tilveiebringer forsikring om at HWID som er sendt tilbake fra denne, er gyldig og korrekt.

Den sikre HWID blir typisk aksessert ved anmodningen fra den betrodde komponent 18, selv om andre anmodere kan anvendes uten å avvike fra foreliggende oppfinnelses ramme. I henhold til en utførelsesform av foreliggende oppfinnelse, og det vises nå til fig. 6, blir den sikre HWID aksessert på følgende måte: Innledningsvis fremskaffer den betrodde komponent 18 ((PU-OEM) S (PR-DRM)) fra ROM-lageret 34 (trinn 601), verifiserer signaturen og verifiserer operativsystemet 32 basert på dette fremskaffede (PU-OEM) (trinn 603). Spesielt, for hver signert fil i operativsystemet 32, verifiserer signaturen til dette, som er basert på (PR-OEM), den betrodde komponent 18 signaturen basert på den fremskaffede (PU-OEM) og basert på attributtene og/eller elementene til de filer som er anvendt for å frembringe signaturen (dvs. selve filen og grunnadressen og lengden til filen i ROM-lageret 34).

Hvis hver signatur blir verifisert, verifiseres likeledes operativsystemet 32 og blir bedømt som pålitelig, og prosessen fortsetter. Hvis ikke, blir operativsystemet 32 bedømt som ikke pålitelig og prosessen stoppes. Hvis det antas at hver signatur blir verifisert og at prosessen fortsetter, undersøker den betrodde komponent 18 deretter drivertabellen 40 i ROM 34 for å lokalisere HWID-driveren 42 (trinn 605), verifiserer signaturen til HWID-driveren 42 (om en slik er tilstede) med (PU-OEM) (trinn 607), og bestemmer om (HWID-driveren 42 innholder en peker tilbake til en adresse i kjernen 38 (trinn 609).

Hvis HWID-driveren 42 verifiseres og inneholder en peker tilbake til en adresse i kjernen 38, kan det forutsettes at HWID-driveren, på riktig måte, vil fremskaffe den sikre HWID fra HWID-komponenten 30 og returnere denne til kjernen 38, idet denne HWID-driveren 42 blir bedømt som pålitelig, og prosessen fortsetter. Hvis ikke, blir HWID-driveren 42 bedømt som ikke pålitelig, og prosessen stop-per. Hvis det antas at HWID-driveren 42 er bedømt som pålitelig, forutsetter den betrodde komponent 18 så at operativsystemet 32 skal stoles på, og anroper i virkeligheten operativsystemet 32 med kjernen 38, drivertabellen 40 og HWID-driveren 42 for å fremskaffe den sikre HWID fra HWID-komponenten 30 og returnerer denne til den betrodde komponent 18 (trinn 611). Som man vil forstå, er anropet til kjernen 38, og kjernen 38 omdirigerer anropet transparent til HWID-driveren 42 ved hjelp av drivertabellen 40, mottar den returnerte, sikre, HWID fra HWID-driveren 42 og videresender denne til den betrodde komponent 18.

Med den sikre HWID fortsetter så den betrodde komponent 18 for å utføre en hvilken som helst oppgave som er nødvendig vedrørende den sikre HWID, innbefattende å verifisere at den betrodde komponent 18 virkelig er på den riktige innretning 14 (trinn 613). Hvis en lisens 16 er bundet til den betrodde komponent 18 (ved f.eks. å innbefatte en innholdsnøkkel (CK) kryptert i henhold til (PU-HW)), er en slik lisens ved utvidelse bundet til den innretning 14 som har den sikre HWID.

KONKLUSJON

Selv om foreliggende oppfinnelse er spesielt nyttig i forbindelse med en innretning 14 med begrenset evne til å generere en sikker HWID på egenhånd, kan foreliggende oppfinnelse praktiseres i forbindelse med enhver passende innret ning, alt uten å avvike fra foreliggende oppfinnelses ramme, slik som f.eks. en personlig datamaskin, en server, et intelligent forbrukerapparat, osv. Følgelig skal innretningen 14 tolkes til å omfatte enhver passende innretning som krever en sikker

HWID.

Den programmering som er nødvendig for å bevirke de prosesser som utfø-res i forbindelse med foreliggende oppfinnelse, er forholdsvis enkel og bør være opplagt for det relevante programmeringspublikum. En slik programmering blir føl-gelig ikke vedføyd her. En hvilken som helst spesiell programmering kan således anvendes til å bevirke foreliggende oppfinnelse uten å avvike fra foreliggende oppfinnelses ramme.

I den foregående beskrivelse, kan det ses at foreliggende oppfinnelse omfatter en ny og nyttig fremgangsmåte og en mekanisme som bibringer en sikker HWID til en innretning 14 i f.eks. det tilfelle hvor maskinvaren ikke er pålitelig nok til å tilveiebringe en sikker HWID. Den leverte sikre HWID kan fremskaffes av operativsystemet 32 i innretningen 14 ved hjelp av en HWID-komponent 30 som levert av en fabrikant av innretningen 14, og HWID-komponenten 30 er pålitelig når det gjelder å bibringe en sikker HWID til innretningen 14 og avdekke en slik sikker HWID for operativsystemet på innretningen 14, hvor den sikre HWID ikke lett kan endres eller misbrukes av en forbrytersk entitet. Man vil forstå at endringer kan gjøres på de utførelsesformer som er beskrevet ovenfor uten å avvike fra de opp-finneriske konsepter. Det skal derfor understrekes at oppfinnelsen ikke er begrenset til de spesielle utførelsesformer som er beskrevet, men er ment å dekke modi-fikasjoner innenfor rammen av den foreliggende oppfinnelse slik den er definert i de vedføyde patentkrav.

Claims (13)

1. Fremgangsmåte for fremstilling av en datainnretning (14) for mottakelse av en digital innholdsdel (13) og en digital lisens (16) for denne, og for å gjengi innholdet i samsvar med lisensen, idet fremgangsmåten sikrer at innretningen kan aksessere en sikker maskinvareidentifikator HWID, individualisering av innretningen og å tillate en betrodd komponent på innretningen å verifisere at den er tiltenkt for innretningen på denne, idet lisensen er ment å bli bundet til den sikre HWID slik at lisensen er ikke-operativ på en annen innretning som har en annen sikker HWID, der fremgangsmåten omfatter: å generere et offentlig (PU-OEM) hemmelig (PR-OEM) nøkkelpar og tilveiebringelse av den offentlige nøkkel (PU-OEM) til en sertifiseringsautoritet; å motta den offentlige nøkkel (PU-OEM) fra sertifiseringsautoriteten med en signatur fra sertifiseringsautoriteten; å anbringe den offentlige nøkkel (PU-OEM) med signaturen i et minne (34) i innretningen; å motta et operativsystem (32) for innretningen fra en ekstern kilde, hvor operativsystemet har flere individuelle komponenter som innbefatter en utførbar kjerne (38), et antall drivere og en drivertabell (40) med en peker til hver driver, der hver av de individuelle komponenter blir fulgt av en signatur utledet fra komponenten; å forsyne innretningen med en fabrikant-forsynt HWID-komponent (30) for å fremskaffe den sikre HWID fra innretningen og videresende den sikre HWID til operativsystemet i innretningen når operativsystemet ber om dette; å anbringe en fabrikant-forsynt HWID-driver spesifikk for HWID-komponenten i ROM-minnet som et tillegg til operativsystemet, idet HWID-driveren er innrettet for å kommunisere med HWID-komponenten for å fremskaffe og videresende den sikre HWID; å anbringe en referanse til HWID-driveren i drivertabellen; og for hver signert komponent i operativsystemet; å verifisere signaturen til komponenten; hvis signaturen er verifisert å fjerne den verifiserte signatur; og å signere komponenten med en hemmelig nøkkel (PR-OEM) svarende til den offentlige nøkkel (PU-OEM), idet signaturen er basert på komponenten, basisadressen og fillengden av komponenten i ROM-minnet; og å plassere komponentene til operativsystemet, innbefattende komponentene med (PR-OEM)-signaturen, i ROM-minnet; å fremskaffe en betrodd komponent fra en sentral autoritet ved å aksessere den sikre HWID fra innretningen og å levere den aksesserte sikre HWID til den sentrale autoriteten; å motta den betrodde komponenten fra den sentrale autoriteten, idet den betrodde komponenten er konstruert slik at den innbefatter den aksesserte sikre HWID og et offentlig/hemmelig nøkkelpar som skal tilknyttes innretningen på en sikker måte og anbringelse av den mottatte betrodde komponenten i et tilbakeskrivbart ikke-flyktig minne i innretningen.

2. Fremgangsmåte ifølge krav 1, hvor HWID-komponenten (30) er én av en del med programvare og maskinvare.

3. Fremgangsmåte ifølge krav 1, videre omfattende å signere HWID-driveren (42) med den hemmelige nøkkelen (PR-OEM) og anbringe signaturen for HWID-driveren i minnet (34).

4. Fremgangsmåte ifølge krav 1, omfattende å anbringe den offentlige nøkke-len (PU-OEM) med signaturen i et bilde (36) som skal bibringes et minne (34) i innretningen (14), å plassere HWID-driveren (42) i bildet som et tillegg til operativsystemet (32), og å plassere komponentene til operativsystemet i bildet, idet fremgangsmåten videre omfatter å levere bildet til innretningens minne.

5. Fremgangsmåte ifølge krav 4, hvor bildet (36) som skal leveres til et minne (34) i innretningen er et ROM-bilde som skal leveres til et ROM-internlager i innretningen, idet fremgangsmåten videre omfatter å levere ROM-bildet til ROM-internlageret i innretningen.

6. Fremgangsmåte ifølge krav 1, hvor det å fremskaffe en betrodd komponent omfatter å levere den aksesserte HWID til autoriteten som en del av en anmodning om den betrodde komponent for innretningen (14), idet autoriteten lager den betrodde komponent slik at den innbefatter den leverte HWID, og slik at den også innbefatter et offentlig/hemmelig nøkkelpar som skal tilknyttes innretningen (PU-HW, PR-HW), hvor HWID og (PR-HW) er innbakt i den betrodde komponent på en sikker måte.

7. Fremgangsmåte ifølge krav 6, hvor den betrodde komponent (18) kan oppdateres fra tid til annen, og hvor minnet (34) som innholder den betrodde komponent, er et ikke-flyktig, omskrivbart internlager (44).

8. Datainnretning for å motta en digital innholdsdel (13) og en digital lisens (16) for denne, og for å gjengi innholdet i samsvar med lisensen, hvor innretningen haren aksesserbar, sikker maskinvareidentifikator (HWID), som individualiserer innretningen og som tillater en betrodd komponent på innretningen å verifisere at den er tiltenkt for innretningen på denne, idet lisensen er bundet til den sikre HWID slik at lisensen er ikke-operativ på en annen innretning som har en annen sikker HWID, der innretningen omfatter: en offentlig nøkkel (PU-OEM) mottatt fra en sertifiseringsautoritet med en signatur fra sertifiseringsautoriteten, idet den offentlige nøkkel (PU-OEM) med signaturen anbringes i et minne (34) i innretningen, der den offentlige nøkkelen (PU-OEM) er generert som del av et offentlig (PU-OEM) hemmelig (PR-OEM) nøkkelpar, og den offentlige nøkkel (PU-OEM) er tilveiebragt til sertifiseringsautoriteten; et operativsystem (32) fra en ekstern kilde som har flere individuelle komponenter anbrakt i ROM-minnet til innretningen, som innbefatter en utførbar kjerne (38), et antall drivere og en drivertabell (40) med en peker til hver driver, der hver av de individuelle komponenter blir fulgt av en signatur utledet fra komponenten og signert med den hemmelige nøkkelen (PR-OEM) svarende til den offentlige nøk-kelen (PU-OEM), idet signaturen er basert på komponenten, basisadressen og fillengden av komponenten i ROM-minnet; en fabrikant-forsynt HWID-komponent (30) for å fremskaffe den sikre HWID fra innretningen og videresende den sikre HWID til operativsystemet i innretningen når operativsystemet ber om den sikre HWID; en fabrikant-forsynt HWID-driver (42) spesifikk for HWID-komponenten og anbrakt i ROM-minnet til innretningen som et tillegg til operativsystemet, idet HWID-driveren for kommunikasjon med HWID-komponenten for å fremskaffe og videresende den sikre HWID til operativsystemet, når operativsystemet anmoder om den sikre HWID, der drivertabellen har en referanse til HWID-driveren deri; en betrodd komponent er anbrakt i et tilbakeskrivbart ikke-flyktig minne i innretningen, idet den betrodde komponenten er anmodet fra en sentral autoritet ved å aksessere den sikre HWID fra innretningen og levere den aksesserte sikre HWID til den sentrale autoriteten, idet den betrodde komponenten mottatt fra den sentral autoriteten er konstruert til å inkludere den aksesserte sikre HWID og et offentlig/hemmelig nøkkelpar tilknyttet innretningen deri på en sikker måte.

9. Innretning ifølge krav 8, hvor HWID-komponenten er enten en programvaredel eller en maskinvaredel.

10. Innretning ifølge krav 8, videre omfattende en signatur for HWID-driveren (42) signert ved hjelp av den hemmelige nøkkelen (PR-OEM).

11. Innretning ifølge krav 10, omfattende å anbringe den offentlige nøkkelen (PU-OEM) med signaturen og komponentene i operativsystemet (32), innbefattende HWID-driveren (42) i et ROM-internlager (34) for innretningen (14).

12. Innretning ifølge krav 8, hvor den betrodde komponent er konstruert for å innbefatte den sikre HWID, og også for å innbefatte et offentlig/hemmelig nøkkel-par som skal tilknyttes innretningen (PU-HW, PR-HW), hvor HWID og (PR-HW) er innbakt i den betrodde komponent på en sikker måte.

13. Fremgangsmåte ifølge krav 12, hvor den betrodde komponent (18) kan oppdateres fra tid til annen, og blir lagret i et ikke-flyktig omskrivbart internlager (44).