NO332737B1 - System og fremgangsmate for beskyttet oppstart av operativsystemet gjennom bruk av statusvalidering. - Google Patents

Abstract

En mekanisme for beskyttet operativsystemoppstart som forhindrer skadelige komponenter fra å bli lastet med operativsystemet og derfor forhindrer avsløring av systemnøkkelen på fell grunnlag. Etter at en del av maskinoppstartsprosedyren har blitt gjennomført eksekverer operativsystemlasteprogrammet, laste- programmet blir validert, og en korrekt maskinstatus blir enten verifisert til å eksistere og/eller blir opprettet. Når lasteprogrammet er blitt verifisert til å være et legitimt lasteprogram, og maskinstatus under den det eksekverer er verifisert til å være korrekt, er lasteprogrammets fremtidig oppførselkjent for å beskytte mot lastingen av skadelige komponenter som kan forårsake avsløringen av systemnøkkelen. Med lasteprogrammets oppførsel kjent for å være trygg for systenmøkkelen kan gyldighetsovervåkeren bryte forseglingen til systenmøkkelen og levere den til lasteprogrammet.

Description

Oppfinnelsens område

Den foreliggende oppfinnelsen relaterer generelt sett til feltet data-behandling. Spesielt tilveiebringer oppfinnelsen en mekanisme til å sikre at et system fortsetter fra en kjent trygg status og denne mekanismen kan brukes ti å starte opp et system på en måte som tilveiebringer tilstrekkelig sikkerhet for at systemet oppfører seg riktig. Denne sikkerheten for riktige oppførsel kan i sin tur hindre at én eller flere nøkler blir frigitt på feil grunnlag.

Oppfinnelsens bakgrunn

Datamaskinsikkerhet er ofte avhengig av at en er i stand til å forutsi oppførselen av programvarekomponenter. Generelt kan sikkerheten til et system bevege seg bort fra forutsetningen, at et kjent program, dens oppførsel er forstått, som fortsetter fra en kjent legal status, fungere på en forutsigbar måte. Omvendt kan ødeleggelsen av sikkerheten - som kan innbefatte at et datamaskinsystem oppfører seg på måter som er utenfor designerens tankegang - generelt sett bli gjennomført ved å erstatte eller endre et kjent program, eller kjøre det i en tilstand hvor oppførselen ikke er forstått. Derfor innbefatter én side ved å tilveiebringe sikkerhet for et databehandlingsmiljø å kontrollere at et kjent program blir brukt og at det tar utgangspunkt i en godkjent tilstand.

Ett område hvor forutsigbarhet av oppførselen er spesielt viktig er ved lasting av et operativsystem og dens komponenter. Til tross for at operativsystemet selv kan være utformet for å tilveiebringe tillit mht dens oppførsel, er tiden før operativsystemet er i gang en tid, da systemet er spesielt sårbart for angrep, siden infrastrukturen som beskytter operativsystemet mot angrep muligens ikke er etablert ennå (eller er under etablering). For å beskytte operativsystemet mot visse klasser av angrep er det derfor viktig å sørge for at det starter opp på en forutsigbar måte.

Én type sikkerhetssprekk som kan forplante seg fra en ikke-sikret oppstart av et operativsystem relaterer til beskyttelse av nøkkelen (eller nøkler) som begrenser funksjonaliteten. Som et ikke begrensende eksempel anvender

MICROSOFT WINDOWS operativsystemer en systemnøkkel, eller "SYSKEY", som brukes til å beskytte forskjellige prosesser ved å gjøre den riktige ytelsen av disse prosesser avhengig av tilgjengeligheten av SYSKEY. For eksempel kan nøkkelen som trengs for å dekryptere privat informasjon som er lagret av operativsystemet i kryptert form være deriverbar fra SYSKEY.

Vanligvis er nøklene som trengs for å gjennomføre begrensede operasjoner, beskyttet av innloggingsprosedyren. Typisk må brukeren legitimere seg (f. eks. ved å tilveiebringe riktige innloggingsakkreditiver, så som en kombinasjon av brukernavn og passord) i forveien for å innlede bruken av systemet. Bruken av nøklene er muliggjort bare dersom brukeren legitimerer seg riktig, og systemet skal bare tillate brukeren et begrenset antall forsøk (f. eks. tre) før det trekkes slutningen at brukeren har feilet å logge inn riktig. (Denne typen av begrensning på antallet forsøk å logge inn hindrer uautoriserte brukere å gjøre bruken av beskyttet funksjonalitet mulig ved å bruke et "brute-force"-angrep for å gjette passordet i tilfellet av f eks en stjålen bærbar datamaskin.) Å bruke innloggingsprosedyren for å beskytte tilgang til nøkler forutsetter imidlertid at operativsystemnedlastingsprogrammet lastet ned operativsystemet på en riktig måte og med det riktige innloggingsprogrammet, og at bruken av nøklene ikke på annen måte har blitt muliggjort av skadelig kode som evt. eksekverer. Dersom det istedenfor ble brukt et skadelig lasteprogram, og det skadelige lasteprogram forårsaker et skadelig innloggingsprogram som lastes med operativsystemet, ville bruken av nøkler kan være muliggjort eller nøklene kan til og med vært avslørt uten at de riktige akkreditivene hadde blitt lagt inn. Siden nedlastingen av operativsystemet tilveiebringer en anledning for en sikkerhetssprekk krever beskyttelse av nøklene i en slik situasjon at lastingen av operativsystemet finner sted under forhold hvor det kan bli verifisert at det foregår korrekt.

Ett problem som oppstår med verifiseringen av sikkerheten i en operativsystemladeprosess er at legitime operativsystemlastinger kan involvere mange forskjellige programmer (f. eks. finnes det mange forskjellige "tilleggs-ROM," som inneholder programmer, som kjører før operativsystemet under en systemoppstartsprosedyre), og det finnes mange forskjellige prosedyrer som kan bli utført som del av operativsystemoppstarten. Derfor finnes det nesten utallige mengder av forskjellige legitime maskintilstander under oppstarten og å identifisere alle slike tilstander og å verifisere at maskinen er i en godkjent tilstand kan vise seg å være en umulig oppgave. Imidlertid har ikke alle deler av lastepro-sedyren sikkerhetskonsekvenser. Det kan være mer effektivt å la lastingen fortsette uten noe forsøk å evaluere dens sikkerhet for så å sette miljøet til en godkjent tilstand før en starter prosedyrer som kan berøre en sikkerhetsrelatert funksjon, så som distribusjonen av nøkler. Generelt kan et vilkårlig system få lov å kjøre en tid uten noe form av sikkerhetsevaluering så lenge systemet kan settes i en godkjent tilstand før handlinger blir tillatt som har sikkerhetskonsekvenser.

US 2003/0196085 A1 beskriver et system og en fremgangsmåte for autentisering av et operativsystem som i samsvar med et aspekt inkluderer en fremgangsmåte i et datamaskinsystem som har en prosessor, et operativsystem, og et programvare-identitetsregister som inneholder en identitet av operativsystemet, idet prosessoren har en privat nøkkel.

På bakgrunn av det foregående finnes det behov for en mekanisme som overvinner ulempene med den kjente teknikken.

Oppsummering av oppfinnelsen

Den foreliggende oppfinnelse vedrører et datamaskinlesbart medium kodet med datamaskineksekverbare instruksjoner for å utføre en fremgangsmåte, kjennetegnet ved at den omfatter: å starte et operativsystemlasteprogram; å validere identiteten eller riktigheten av lasteprogrammet; å sikre at maskinen på hvilken operativsystemlasteprogrammet eksekverer, er i en kjent tilstand; og dersom identiteten eller riktigheten av lasteprogram viser seg, og dersom maskinen hvor operativsystemet eksekverer er i en kjent tilstand, da: tilveiebringe en nøkkel til lasteprogrammet; og tillate lasteprogrammet å laste et operativsystem.

Den foreliggende oppfinnelse vedrører også et system for å utføre en oppstart av et operativsystem under forhold som tilveiebringer sikkerhet i forhold til påliteligheten av oppstarten, kjennetegnet ved at systemet omfatter: en gyldighetsovervåker som evaluerer riktigheten eller identiteten til et operativsystemlasteprogram som skal laste operativsystemet, og som videre evaluerer tilstanden til en maskin på hvilken operativsystemlasteprogrammet skal operere som enten tillater eller forbyr operativsystemlasteprogrammet til å fortsette med å laste operativsystemet avhengig av om riktigheten eller identiteten av operativsystemlasteprogrammet er verifisert eller ikke, og som plasserer denne maskinen i en kjent tilstand før den tillater operativsystemlasteprogrammet å fortsette.

Den foreliggende oppfinnelse vedrører videre en fremgangsmåte med å starte et operativsystem, kjennetegnet ved at den omfatter: å eksekvere et grunnleggende inn/ut-system, en tilleggs-ROM, et hovedoppstartsdatasett og en oppstart sektor; å starte et operativsystemlasteprogram; å godkjenne operativsystemlasteprogrammet; å godkjenne en tilstand til en maskin på hvilken operativsystemlasteprogrammet eksekverer; dersom operativsystemlasteprogrammet og tilstanden av maskinen er validert til å være rett, å tillate at operativsystemlasteprogrammet laster et operativsystem.

Andre utførelsesformer av det datamaskinlesbare medium i henhold til oppfinnelsen, systemet i henhold til oppfinnelsen og fremgangsmåten i henhold til oppfinnelsen fremgår av de uselvstendige patentkrav.

Det beskrives oppstart av et operativsystem under forhold hvor oppstarten kan verifiseres å bli gjennomført korrekt. Når en maskin startes utføres den initiale oppstartsprosedyren (f. eks. BIOS, tilleggs-ROM, hovedoppstartsdatasett, oppstartsektor, etc). Etter at disse tidlige prosedyrene er utført startes lasteprogrammet til operativsystemet som utfører forskjellige foreløpige oppgaver. Etter at operativsystemlasteprogrammet er startet og har utført slike foreløpige oppgaver utføres en validering av operativsystemlasteprogrammet.

Valideringen omfatter gyldighetstester på lasteprogrammet selv eller en del av lasteprogrammet (f. eks., kontrollsummer eller andre tester som er rettet mot å evaluere identiteten og korrektheten av lasteprogrammet) så vel som å evaluere den løpende maskintilstanden (eller å tvinge maskinen til å overholde en godkjent tilstand). Dersom lasteprogrammet (eller en relevant del av dette) er erkjent å være rett, og maskintilstanden er én hvor lasteprogrammet før har blitt verifisert til å oppføre seg korrekt kan oppførselen av lasteprogrammet bli forutsagt. Derfor kan en være sikker på at et korrekt lasteprogram som arbeider i en korrekt maskintilstand, ikke henter en komponent som ville forårsake at data som muliggjør beskyttede funksjoner (f. eks. kryptografiske nøkler så som systemnøkkelen), blir frigitt på feil grunnlag.

Fortrinnsvis utføres valideringen av en gyldighetsovervåker som eksekverer i et høysikkerhetsmiljø. Et høysikkerhetsmiljø er et miljø hvor det er mulig å tilveiebringe en forholdsvis høy grad av sikkerhet for at prosesser som utføres der, vil eksekvere på den måten de er forventet å eksekvere. Derfor er sikkerheten at gyldighetsovervåkeren opererer korrekt utledet fra det faktum at gyldighetsovervåkeren er verifisert av en prosess som eksekverer i høysikkerhets-miljøet (f. eks. ved å verifisere en signatur av dens binærfil) og fra den under-liggende tillitten at prosesser i høysikkerhetsmiljøet vil bli utført korrekt. (Eller i det minste at det finnes et minstemål av sikkerhet at høysikkerhetsmiljøet ikke skal komme i konflikt eller tillate interferens med den rette driften av en prosess som opererer innenfor et slikt miljø; én må fortsatt ha et separat tillitsgrunnlag for at programmet som implementerer en prosess innenfor høysikkerhetsmiljøet vil eksekvere korrekt på den måten, at den utfører oppgaven som forventet.) Et høysikkerhetsmiljø kan tilveiebringe forseglet lagring som er en lagringsanordning hvor data kan være knyttet sammen med et spesielt objekt (f eks med et spesielt program), og at høysikkerhetsmiljøet kontrollerer på en måte at de forseglede data ikke gis til noe annet objekt enn det éne som dataene er koblet til (som verifisert av høysikkerhetsmiljøet). Gyldighetsovervåkeren kan bruke det forseglende lager til å knytte en nøkkel (f. eks. SYSKEY) til seg selv og kan nekte å bryte forseglingen unntatt for det riktige objektet og når forholdene (f. eks. maskintilstanden) oppfyller standarden på en tilfredsstillende måte.

Andre kjennetegn av oppfinnelsen er beskrevet nedenfor.

Kort beskrivelse av tegningene

Den foregående oppsummeringen så vel som den følgende detaljerte beskrivelsen av foretrukne utførelsesformer er bedre forstått når den leses sammen med de vedlagte tegningene. For å illustrere oppfinnelsen finnes i tegningene eksempelkonstruksjoner av oppfinnelsen; imidlertid er oppfinnelsen ikke begrenset til den spesifikke fremgangsmåten og fremlagde hjelpemidler. I tegningene er

figur 1 et blokkdiagram av et eksempelvis databehandlingsmiljø hvor sider av oppfinnelsen kan være implementert;

figur 2 er et blokkdiagram av et system som anvender en prosess dens korrekte drift er avhengig av en systemnøkkel;

figur 3 et blokkdiagram av et kryptert filsystem som beskytter kryptert data fra uautorisert dekryptering ved å gjøre dekrypteringen avhengig av en systemnøkkel;

figur 4 et flytdiagram av en eksempelvis oppstartsprosess med validering i samsvar med sider ved oppfinnelsen;

figur 5 et blokkdiagram av en eksempelvis gyldighetsovervåker i samsvar med sider ved oppfinnelsen; og

figur 6 et flytdiagram av en eksempelprosess som beskytter en systemnøkkel i samsvar med sider ved oppfinnelsen.

Detaljert beskrivelse av illustrative utførelsesformer

Oversikt

Flere prosesser som kan eksekvere under et operativsystem er avhengig av én eller flere nøkler for å fungere riktig. Tilgangen til nøklene kan være kontrollert av et autentiseringsprogram så som et innloggingsprogram som nekter å frigi bruk av nøkkelen (nøklene) med mindre brukeren tilveiebringer riktige akkreditiver, så som en brukernavn/passordkombinasjon. Pga innloggings-programmets nektelse å frigi nøkler ved fravær av riktige akkreditiver kan derfor flere prosesser (f. eks. dekryptert av krypterte filer) være forstyrret (eller helt stanset) for brukere som ikke kjenner passordet. Mens innloggingsprogrammet kan være effektivt med å styre tilgangen til nøklene kan et operativsystemlasteprogram bli lurt til å laste en annen komponent som ville distribuere nøklene utenfor legitimeringsreglene pålagt av innloggingsprogrammet. Når nøkler blir frigitt på denne måten kreves det derfor å beskytte operativsystemlasteprosessen når nøklene skal beskyttes. Den foreliggende oppfinnelsen tilveiebringer mekanismer som kan brukes til å beskytte lasteprosessen.

Eksempelvis databehandlingsoppsett

Figur 1 viser et eksempelvis databehandlingsmiljø hvor sider av oppfinnelsen kan være implementert. Databehandlingsmiljøet 100 er bare ett eksempel av et passende databehandlingsmiljø og skal ikke antyde noen begrensninger mht bruksomfanget eller funksjonaliteten av oppfinnelsen. Heller ikke burde databehandlingsmiljøet 100 være tolket som å ha noe avhengighet eller krav relatert til en enkel eller kombinasjon av komponenter illustrert i det eksempelvise miljø 100.

Oppfinnelsen kan brukes med mange andre universelle eller spesielle databehandlingsmiljøer eller konfigurasjoner. Eksempler av kjente databe-handlingssystemer, miljøer og/eller konfigurasjoner som kan passe til bruk med oppfinnelsen, innbefatter, men er ikke begrenset til, personlige datamaskiner, serverdatamaskiner, håndholdte eller bærbare anordninger, flerprosessor-systemer, mikroprosessorbaserte systemer, TV-konvertere, programmerbar forbrukerelektronikk, nettverks-PCer, minidatamaskiner, stordatamaskiner, integrerte systemer, spredte databehandlingsmiljøer, som innbefatter hvilken som helst av de ovenfor stående systemene eller anordninger og liknende.

Oppfinnelsen kan beskrives i den generelle sammenhengen med datamaskineksekverbare instruksjoner, så som programmoduler som utføres av en datamaskin. Generelt innbefatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer osv. som utfører spesielle oppgaver eller implementerer spesielle abstrakte datatyper. Oppfinnelsen kan også utøves i spredte databehandlingsmiljøer hvor oppgaver utføres av fjerntliggende behand-lingsanordninger som er tilkoblet gjennom et kommunikasjonsnettverk eller andre dataoverføringsmedier. I et spredt databehandlingsmiljø kan programmoduler og andre data være lokalisert i både lokale og fjerntliggende lagringsmedia for datamaskiner omfattende minneanordninger.

Med referanse til figur 1 innbefatter et eksempelvis system for å implementere oppfinnelsen en universell databehandlingsanordning utformet som en datamaskin 110. Komponentene av datamaskin 110 kan innbefatte, men er ikke begrenset til, en prosessor 120, et systemminne 130 og en systembuss 121 som kobler forskjellige systemkomponenter omfattende systemminnet til prosessorenheten 120 sammen. Prosessoren 120 kan representere mangfoldige logiske prosessorenheter, så som slike støttet på en flertrådsprosessor. Systembussen 121 kan være hvilken som helst av flere typer av busstrukturer omfattende en minnebuss eller en minnekontrollenhet, en periferibuss og en lokal buss som bruker hvilken som helst av et mangfold av bussarkitekturer. Som eksempel og ikke en begrensning innbefatter slike arkitekturer 'Industry Standard Architecture' (ISA)-buss, 'Micro Channel Architecture' (MCA)-buss, 'Enhanced ISA'

(EISA)-buss, 'Video Electronics Standards Association' (VESA)-lokalbuss og 'Peripheral Component Interconnect' (PCI)-buss (også kjent som Mezzanine buss). Systembussen 121 kan også være implementert som en punkt-til-punkt-kobling, svitsjende struktur, eller liknende bland kommunikasjonsanordningene.

Datamaskinen 110 innbefatter typisk et mangfold av datamaskinlesbare medier. Datamaskinlesbare medier kan være et hvilket som helst tilgjengelig medium som kan aksesseres av datamaskinen 110 og innbefatter både flyktige og ikke-flyktige medier, fjernbare og ikke-fjernbare medier. Som et eksempel og ikke en begrensning kan datamaskinlesbare medier innbefatte lagringsmedier for datamaskiner og kommunikasjonsmedier. Lagringsmedier for datamaskiner innbefatter både flyktige og ikke-flyktige, fjernbare og ikke-fjernbare medier implementert med hvilken som helst fremgangsmåte eller teknologi for lagring av informasjon så som datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data. Lagringsmedia for datamaskiner omfatter, men oppfinnelsen er ikke begrenset til det, RAM, ROM, EEPROM, flash-minne eller andre minneteknologier, CD-ROM, 'digital versatile disks' (DVD) eller andre optiske platelager, magnetiske kassetter, magnetisk bånd, magnetiske platelager eller andre magnetiske lagringsanordninger eller hvilken som helst andre medier som kan brukes til å lagre den ønskede informasjon og som kan aksesseres av datamaskinen 110. Kommunikasjonsmedier rommer typisk datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal så som en bærebølge eller andre transportmekanismer og innbefatter et hvilken som helst informasjonsleveringsmedium. Uttrykket "modulert datasignal" betyr et signal som har én eller flere av dens karakteristika satt eller endret på en slik måte, at informasjonen preges på signalet. Som et eksempel og ikke en begrensning innbefatter kommunikasjonsmedier kablede medier så som et kablet nettverk eller en direkte kabeltilkobling og trådløse medier så som akustiske, radiobølge, infrarød og andre trådløse medier. Kombinasjoner av hvilken som helst av det ovenfor stående burde også være inkludert innenfor omfanget av datamaskinlesbare medier.

Systemminnet 130 innbefatter lagringsmedier for datamaskiner i form av flyktig og/eller ikke-flyktig minne så som ROM 131 og lese/skrive-minne (RAM) 132. Et grunnleggende inn/ut-system 133 (BIOS) inneholdende de grunnleggende rutinene som hjelper å overføre informasjon mellom elementer innenfor datamaskin 110, så som under oppstart, er typisk lagret i ROM 131. RAM 132 inneholder typisk data og/eller programmoduler som er umiddelbart aksesserbare for og/eller i øyeblikket under behandlingen av prosessoren 120. Som et eksempel og ikke en begrensning illustrerer figur 1 operativsystemet 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137.

Datamaskinen 110 kan også innbefatte andre fjernbare/ikke-fjernbare, flyktige/ikke-flyktig lagringsmedier for datamaskiner. Bare som et eksempel illustrerer figur 1 en platelagerstasjon 141 som leser fra eller skriver til ikke-fjernbare, ikke-flyktige magnetiske medier, en magnetisk platestasjon 151, som leser fra eller skriver til en fjernbar, ikke-flyktig magnetisk plate 152 og en optisk platestasjon 155, som leser fra eller skriver til en fjernbar, ikke-flyktig optisk plate 156, så som en CD-ROM eller andre optiske medier. Andre fjernbare/ikke-fjernbare, flyktige/ikke-flyktige lagringsmedier for datamaskiner som kan brukes i det eksempelvise driftsmiljøet innbefatter, men er ikke begrenset til, magnetiske bånd kassetter, flash-minnekort, 'digital versatile disks' (DVD), digital videobånd, halvleder-RAM, halvleder-ROM og liknende. Platelagerstasjonen 141 er typisk tilkoblet systembussen 121 gjennom et ikke-fjernbart minnegrensesnitt så som grensesnitt 140 og den magnetiske platestasjon 151 og optiske platestasjon 155 er typisk tilkoblet systembussen 121 vha et grensesnitt for fjernbare lagringsen-heter så som grensesnitt 150.

Stasjonene og dens assosierte lagringsmedier for datamaskiner 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 platelagerstasjonen 141 illustrert som at den lagrer operativsystemet 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147. Bemerk at disse komponentene kan enten være det samme eller forskjellig fra operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137. Operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147 er gitt forskjellige nummer her for å vise at det er minst forskjellige kopier. En bruker kan legge inn kommandoer og informasjon i datamaskin 20 gjennom innmatingsanordninger så som et tastatur 162 og en pekeanordning 161, vanligvis kalt mus, trackball eller navigeringsplate. Andre innmatingsanordninger (ikke vist) kan innbefatte mikrofon, joystick, spillpute, parabolantenne, skanner eller liknende. Disse og andre innmatingsanordninger er ofte tilkoblet prosessorenheten 120 gjennom et brukerinputgrensesnitt 160 som er koblet til systembussen, men kan være tilkoblet med andre grensesnitt og busstrukturer så som en parallelport, spillport eller en 'universal serial bus' (USB)-buss. En monitor 191 eller annen type av fremvisningsanordning er også tilkoblet systembussen 121 via et grensesnitt så som et videogrensesnitt 190.1 tillegg til monitoren kan datamaskiner også innbefatte andre perifere utgangsanordninger så som høyttalere 197 og skrivere 196 som kan være tilkoblet gjennom et grensesnitt 195 for utmatingsperiferi.

Datamaskinen 110 kan operere i et nettverksmiljø som bruker logiske tilkoblinger til én eller flere fjerntliggende datamaskiner så som en fjerntliggende datamaskin 180. Den fjerntliggende datamaskinen 180 kan være en personlig datamaskin, en server, en router, et nettverks-PC, en likestilt anordning ('peer') eller en annen vanlig nettverksnode og innbefatter typisk mange eller alle av de elementene beskrevet ovenfor i forhold til datamaskinen 110, til tross for at bare en minneanordning 181 er illustrert i figur 1. De logiske tilkoblingene beskrevet i figur 1 innbefatter et lokalnett (LAN) 171 og et 'wide area network ' (WAN) 173, men kan også innbefatte andre nettverk. Slike nettverksmiljøer er vanlig i kontorer, bedriftsomfattende datamaskinnettverk, intranett og internettet.

Når brukt i et LAN-nettverksmiljø er datamaskinen 110 tilkoblet LAN 171 gjennom et nettverkskort eller -adapter 170. Når brukt i et WAN-nettverksmiljø innbefatter datamaskin 110 typisk et modem 172 eller andre midler for etablering av kommunikasjon over WAN 173, så som internettet. Modemet 172 som kan være internt eller eksternt, kan være tilkoblet systembussen 121 via brukerinputgrensesnitt 160 eller andre passende mekanismer. I et nettverkstilkoblet miljø kan programmoduler beskrevet i forhold til datamaskinen 110, eller deler derav, være lagret i den fjerntliggende minneanordningen. Som et eksempel og ikke en be grensning illustrerer figur 1 fjerntliggende applikasjonsprogrammer 185 som ligger på minneanordning 181. Det skal forstås at de illustrerte nettverkstilkoblingene står som eksempler, og andre hjelpemidler til etablering av en kommunikasjons-kanal mellom datamaskinene kan brukes.

Handlinger beskyttet av nøkler

Et databehandlingsmiljø kan anvende en nøkkel som visse prosesser som eksekverer innenfor miljøet, er avhengig av for å fungere riktig. System-nøkkelen, eller "SYSKEY", brukt i MICROSOFT WINDOWS operativsystemer er ett eksempel av en slik nøkkel, men er ikke et begrensende eksempel. I en foretrukket utførelsesform er en nøkkel som en prosess er avhengig av, en unik, kryptografisk tilfeldig nøkkel på plattformbasis, - dvs. gitt to maskiner er det sannsynlig at de to maskiner har forskjellige nøkler. Derfor er en prosess som er avhengig av slike nøkler sannsynligvis ikke porterbar fra én plattform til en annen - i det minste i den utstrekning som effektive mekanismer brukes for å trygge at den ene plattformens nøkkel er utilgjengelig utenfor denne plattformen.

Figur 2 viser et eksempelsystem hvor en prosess eksekverer som er avhengig av en nøkkel. Prosess 202 er avhengig av nøkkel 204 for å operere riktig. Det skal bemerkes at prosess 202 ikke er begrenset til det tradisjonelle begrep av en prosess - dvs. en eksekveringsenhet som kan være styrt av et operativsystem og tilordnet et adresserom - men heller refererer mer generelt til en operasjon eller serie av operasjoner som kan utføres på en datamaskin. Videre burde det vært nevnt at, mens dette eksempel viser en prosess som er avhengig av en kryptografisk nøkkel, er uttrykket "prosess" som brukes her ikke begrenset på prosesser som utfører kryptogråfiske operasjoner.

Som vist i figur 2 opererer prosess 202 korrekt dersom nøkkel 204 er tilgjengelig som input for prosess 202. Dersom nøkkel 204 på den andre siden ikke er tilgjengelig som en input for prosess 202 fungerer prosess 202 ikke riktig. En nøkkelbeskyttelsesmekanisme 206 kontrollerer tilgangen til nøkkel 204 - dvs. mekanismen 206 enten forsyner eller ikke forsyner prosess 202 med nøkkel 204, avhengig av om de relevante sikkerhetsbetingelsene har blitt oppfylt. For eksempel må en bruker logge inn og tilveiebringe et riktig passord før mekanisme 206 skal frigi bruken av nøkkel 204.

Det skal bemerkes at nektelsen av nøkkel 204 for å forhindre at prosess 202 fungerer riktig er noen ganger et ønskelig resultat. For eksempel er krypteringen/dekrypteringen av filer ett eksempel for en prosess 202 som er beskyttet av nøkkel 204. Den riktige dekrypteringen av en fil kan være avhengig av tilgang til nøkkel 204. Dersom brukeren ikke kan logge inn og legitimere seg selv kan det være ønskelig for dekrypteringen av en fil å ikke fortsette siden en bruker som ikke er i stand til å logge inn, kan indikere at datamaskinen brukes av en annen enn dens tiltenkte bruker (f. eks. i tilfellet av en stjålen laptop-datamaskin). Derfor kan nøkkelbeskyttelsesmekanisme 206 gi tilgang til nøkkel 204 avhengig av oppfyllelsen av relevante sikkerhetsbetingelser og kan nekte bruken av nøkkel 204 for å stanse prosesser som skal avbrytes når disse sikkerhetsbetingelsene ikke er oppfylt. Mekanisme 206 sin evne å avbryte prosesser på denne måten er avhengig av at disse prosesser krever nøkkel 204 for å fungere korrekt siden det er denne avhengigheten som gjør det mulig å nekte nøkkel 204 for å avbryte prosessen.

Figur 3 viser et spesifikt (men ikke begrensende) eksempel av en prosess som er avhengig av nøkkel 204.1 eksempelet i figur 3 er eksempel-prosessen et krypterende filsystem (EFS) 302 som lagrer filer i kryptert form og dekrypterer også de krypterte filene. Det skal bemerkes at ett formål av slike filkrypteringer er å beskytte data på en bærbar datamaskin fra å bli hentet ut av en tyv i tilfelle hvor laptop-datamaskinen er stjålet. Når en fil 304 er generert for lagring leveres den til EFS 302. EFS 302 krypterer da filen 304 og omformer fil 304 til den krypterte filen 306 som lagres på platelager 141. Når en anmodning kommer for å hente kryptert fil 306, henter EFS 302 den krypterte filen 306 og dekrypterer den for å generere den dekrypterte fil 308. (I praksis er innholdet av den dekrypterte fil 308 det samme som original fil 304 til tross for at figur 3 viser disse to forekomstene av filen separat for klarhetens skyld: fil 304 er den originale filen, og den dekrypterte fil 308 er samme fil etter at den har vært kryptert, lagret, hentet opp igjen og dekryptert av EFS 302.)

Det skal bemerkes at én input til EFS 302 er innholdsnøkkel 310. Innholdsnøkkel 310 er fortrinnsvis en symmetrisk nøkkel som fungerer som input til en kryptografisk fremgangsmåte. Innholdsnøkkel 310 er brukt for å kryptere fil 304 for å opprette den krypterte filen 306 og er også brukt for å dekryptere den krypterte filen 306 for å opprette den dekrypterte filen 308. Det skal forstås at å lagre nøkkelen 310 i noen lett tilgjengelige plasser kan raskt gjøre EFS 302's evne å beskytte data ineffektiv. Dersom innholdsnøkkelen er lett tilgjengelig på et platelager, eller dersom det enkelt kan utledes fra noen kjennetegn av laptop-datamaskinen (f. eks., prosessorens serienummer) ville det ikke gjøre noen forskjell om filene var lagret i kryptert form siden en tyv lett kan finne nøkkelen og dekryptere de. For å beskytte nøkkelen er det derfor ønskelig å utlede den på en måte som bare kan bli gjort i samarbeid med den rette eieren. Én vei å beskytte nøkkelen er å bruke en nøkkelgeneratormodul 312 som mottar nøkkel 204 som input og utleder innholdsnøkkel 310 som en funksjon av nøkkel 204.1 den utstrekning at nøkkel 204 bare skal tilveiebringes under tilstrekkelig sikre forhold, er det derfor likeså sant at innholdsnøkkel 310 bare skal være deriverbar under passende forhold. Med andre ord: ved å gjøre utledningen av innholdsnøkkelen 310 avhengig av tilgjengeligheten av nøkkel 204 kan hvilken som helst beskyttelse en tar seg råd til for nøkkel 204, videreføres til innholdsnøkkelen 310. Dersom for eksempel tilveiebringelse av nøkkel 204 krever at brukeren logger inn ved å tilveiebringe det riktig passord, kan en være sikker på at innholdsnøkkelen 310 ikke vil være tilgjengelig med mindre brukeren logger inn korrekt.

Derfor er det viktig å beskytte nøkkel 204 fra å bli utlevert på feil grunnlag siden andre prosesser kan være avhengig av at nøkkel 204 er utlevert bare i den riktige sikkerhetssammenhengen (f. eks. en legitim, pålogget bruker som

oppgir det riktige passordet). Som beskrevet nedenfor er én vei å få en maskin til å distribuere nøkkel 204 på en måte som kan føre til misbruk, å oppstarte maskinen i et usikkert miljø hvor skadelige komponenter av operativsystemet kan erstatte de legale komponentene (hvor de legale komponentene er antatt å være i stand til å beskytte nøkkel 204). Mekanismer som sørger for at en maskin er oppstartet i et kjent (trygd) miljø før nøkkel 204 kan bli frigitt blir derfor beskrevet nedenfor.

Oppstartsprosess med tilstandsvalidering

Figur 4 viser en typisk rekkefølge av hendelser som brukes i en oppstartsprosedyre.

Til å begynne med blir maskinen slått på. En typisk maskin er konfigurert til å begynne å eksekvere instruksjoner ved en fast adresse ved det tidspunktet den er slått på. Instruksjonene som typisk finnes ved denne adressen er kjent som "BIOS" 402, eller det "grunnleggende inn/ut-system". Ved slutten av BIOS 402 sin eksekvering begynner BIOS 402 eksekveringen av små programmer kalt "tilleggs-ROM" 404. Tilleggs-ROM er programmer som utfører veldig grunnleggende funksjoner i den tidlige fasen av oppstarten, så som å sette maskinvare-passordet for maskinen eller velge ut hvilken av flere operativsystemer som skal hentes. Etter at tilleggs-ROM'ene 404 er eksekvert blir maskinen instruert til å laste hovedoppstartsdatasettet (MBR) 406.

MBR 406 er et eksekverbart program. Typisk befinner MBR 406 seg på den første sektoren av datamaskinens platelager og begynner ved å slå opp i partisjonstabellen hvilken partisjon som skal brukes i den videre oppstarten. (For eksempel kan en plate være partisjonert for bruk med forskjellige operativsystemer og hvert operativsystem kan kreve en annen oppstartsprosedyre.) Etter at den riktige partisjonen har blitt slått opp overfører MBR 406 kontrollen til oppstartssektoren 408 som er assosiert med denne partisjonen. Oppstartssektoren innleder da prosessen med å laste operativsystemlasteprogrammet 410 som til slutt skal hente operativsystemet. Det skal bemerkes at MBR 406 vises i figur 4 bare for å vise hvordan en slik komponent ville passe i en eksempelvis oppstartsprosess og oppfinnelsen er ikke begrenset til oppstartsprosedyrer som bruker MBR 406.

I tiden hvor operativsystemlasteprogrammet 410 kjører er lasteprogrammet og maskintilstanden godkjent (450). ("Maskin" kan i denne sammenheng henvise til enten en fysisk maskin eller en virtuell maskin. Godkjennelsen blir utført av en programvarekomponent med tillit som opererer i et høysikkerhetsmiljø (en utførelsesform av det som er beskrevet nærmere nedenfor), og derfor finnes noen grad av sikkerhet/tillit at valideringen av lasteprogrammet 410 blir gjort riktig. Ved i hovedsak å godkjenne de relevante sidene av maskinens tilstand mens operativsystemlasteprogrammet 410 har kontroll med maskinen og ved å godkjenne lasteprogrammet 410 er det mulig å tilveiebringe en viss sikkerhet for at illegitime eller skadelige versjoner av operativsystemkomponenter (f eks. maskinvareabstraksjonslaget, kjernen, drivere, osv.) 416 ikke lastes inn senere, frem til den tiden hvor innloggingsprogrammet 418 eksekverer. Å hindre skadelige komponenter å bli lastet inn frem til den tiden hvor innloggingsprogram 418 starter er viktig, fordi én av de første tingene operativsystemet skal gjøre etter at det er lastet, er å kjøre et innloggingsprogram 418 som styrer tilgangen til nøkkel 204, og dersom skadelige komponenter kan være lastet ville disse komponentene kan forårsake at innloggingsprogram 418 oppfører seg feil på en måte som kan resultere i at nøkkel 204 blir frigitt på feil grunnlag og dermed kompromittere sikkerheten av alle komponentene som avhenger av beskyttelsen av nøkkel 204 som beskrevet ovenfor. Derfor kan beskyttelsen av nøkkel 204 være oppnådd ved å utøve tett kontroll over maskinens tilstand fra tiden da operativsystemlasteprogrammet 410 startes til innloggingsprogrammet har avsluttet.

Validering 450 finner sted i den tiden når operativsystemlasteprogrammet 410 eksekverer. Valideringen innbefatter å godkjenne lasteprogrammet og maskintilstanden og kan også innbefatte å sette maskintilstanden til en godkjent tilstand. Den grunnleggende ideen bak å godkjenne og innstille maskintilstanden er å bringe maskinen i en tilstand hvor, dersom lasteprogrammet eksekverer mens maskinen er i denne tilstanden, lasteprogrammet ikke vil laste skadelige komponenter eller ellers oppføre seg på måter som ville føre til sikker-hetsproblemer. Validering 450 sørger for at lasteprogramkoden er faktisk den koden som har vært verifisert før, at den oppfører seg riktig, og sørger også for at maskinen er i en tilstand, i hvilken denne kjente koden vil oppføre seg riktig (enten ved å verifisere at maskinen allerede er i denne tilstanden eller ved å sette maskinen i denne tilstanden). Det skal forstås at denne teknikken er i stand til å forbedre den eksisterende (trygge) tilstanden av maskinen for å sikre at fremtidige tilstander av maskinen også skal være trygg, og dette løft er gjort mulig av det faktum at oppførselen av operativsystemlasteprogrammet 410 ikke bare er kjent og forstått, men også tett avgrenset. Basert på denne observasjon skal det forstås at validering 450 burde ikke skje for tidlig (f eks. ved tidspunktet når tilleggs-ROMs 404 eller MBR 406 eksekverer) siden det store mangfold av kode fra mange forskjellige kilder og den store bredden av tilstander som maskinen kan inneha som et resultat av å eksekvere slik kode, gjør det vanskelig, hvis ikke umulig, å bestemme oppførselen til maskinen mens den eksekverer alle disse forskjellige kodemoduler. Derfor skal en helst ikke bry seg om i hvilke tilstander maskinen er før kjøringen av lasteprogrammet 410, så lenge maskinen kan settes i en legitim tilstand ved tidspunktet når lasteprogrammet 410 eksekverer.

I en foretrukket utførelsesform er eksekveringen av lasteprogram 410 delt opp i to trinn: trinn 1 (412) og trinn 2 (414). Fortrinnsvis er koden som implementerer trinn 2 godkjent (450) før trinn 2 begynner, og koden med tillitt som utfører validering 450 hopper da inn i trinn 2 ved et klart angitt startpunkt.

("Tillitskoden" som utfører valideringen er ovenfor nevnt program som eksekverer i et høysikkerhetsmiljø. Fagpersonen vil forstå at "tillitt" ikke impliserer absolutt ufeilbarlighet, men bare betyr at det finnes noe grunnlag for å anta at koden skal gjøre jobben riktig. Å utføre "tillitskode" i et høysikkerhetsmiljø betyr at tillitskoden skal operere riktig, siden oppførselen av et program kan bli berørt av miljøet hvor det eksekverer: (1) i et miljø som oppfyller noen forventninger kan en stole på at tillitskoden utfører sin funksjon korrekt og (2) en kan stole på at et høysikkerhets-miljøet på en korrekt måte tilveiebringer et miljø som oppfyller slike forventninger. Trinn 2 kan da godkjenne (i henhold til noen definerte standarder) hvilken som helst informasjon som det har mottatt fra trinn 1. Skillelinjen mellom trinn 1 og trinn 2 reflekterer det faktum at det kan være noen sider ved en oppstartsprosedyre som kan utføres uten noen sikkerhetskontroll og uten å ha konsekvenser for noen sikkerhetsrelaterte oppgaver (så som distribusjonen av nøkkel 204), så lenge de relevante programmene og tilstanden kan godkjennes et sted før hendelser kan bli satt i gang som kan forårsake at en slik sikkerhetsrelatert oppgave ikke utføres riktig. Videre kan det være problematisk å forsøke å godkjenne tilstanden for tidlig i oppstartsprosessen: det aktuelle programforløp som en legitim oppstartsprosedyre kan ta, er ganske variabel slik at det blir vanskelig å definere forskjellen mellom gyldige eller ugyldige maskintilstander under slike variable forhold. Det kan være fornuftig å ganske enkelt tillate at lastingen fortsetter gjennom disse variable tilstander uten å prøve å bestemme om tilstandene som maskinen går gjennom er rett. Trinn 1 representerer derfor den delen av lastingen som fortsetter uten noe validering. Ved slutten av trinn 1 er lasteprogrammet og maskintilstanden godkjent og trinn 2 begynner. Antakelsen av en slik skillelinje er at prosesser kan eksekvere uten sikkerhetsbegrensninger opp til et visst punkt

hvor alle faktorer om maskinen er godkjente og maskinen er satt i en godkjent tilstand, som i praksis tilintetgjør effekten av tidligere handlinger som kan ha fått maskinen i en tilstand som er uakseptabel fra et sikkerhetsstandpunkt. Det eksakte punkt i lasteprosessen hvor skillelinjen mellom trinn 1 og trinn 2 ligger, er meget spesifikt for forholdene (f. eks. hvordan ser lasteprogramkoden ut, hvilke oppgaver trenger å bli gjort som del av lastingen?) og er et kompromiss: på den ene siden burde skillelinjen ligge sent nok at, for fremtidige handlinger, mengden av variasjon i legitim lastingsoppførsel er liten nok til at legitim oppførsel er mulig å bli skilt fra illegitim oppførsel. (Som nevnt ovenfor gjør det store antall av tilleggs-ROM og andre variabler tidlig i lastingsprosedyren antallet av mulige program-forløp så stor at det er vanskelig å skjelne legitim oppførsel fra illegitim oppførsel.) På den andre siden burde skillelinjen ligge tidlig nok til at den kommer før hendelser (f. eks. lastingen av innloggingsprogrammet) som kan har berørt sikkerheten, så som å forårsake at nøkler, blir frigitt på feil grunnlag. Generelt tillater skillelinjen mellom trinn 1 og trinn 2 at en eksekverer et vilkårlig system i en "rå" (eller "åpen" eller "ikke-godkjent") tilstand i en tid og så starter alle nødvendige komponenter (f. eks. et høysikkerhetsmiljø) for å verifisere oppførselen og så bruke slike komponenter for å godkjenne maskinens tilstand (eller tvinge maskinen i en godkjent tilstand), på hvilket punkt prosessen som gjør noe som senere kan påvirke sikkerheten (f. eks. distribusjonen av nøkler) kan få tillatelse å fortsette.

Valideringen 450

Validering 450 er i hovedsak å verifisere at operativsystemlasteprogrammet 410 (eller rettere sagt: i en foretrukket utførelsesform å verifisere at trinn 2 av lasteprogrammet) er et kjent program med tillitt, og å sikre at maskinen det eksekverer på, er i en godkjent tilstand. Derfor har valideringen to deler: (1) å sjekke lasteprogrammet (eller trinn 2 av lasteprogrammet) for å sikre at det er det kjente program med tillitt som det en tror det er, og (2) endre den relevante maskintilstanden til en godkjent tilstand under hvilken lasteprogrammet er kjent til å oppføre seg riktig. Forutsetningen med å utføre (1) og (2) er at et kjent program som eksekverer under en kjent maskintilstand, vil oppføre seg på en kjent måte.

Den første delen av valideringen - dvs. å kontrollere lasteprogrammet - kan være utført på mange måter. I det enkleste eksempel kan en hash-kode av det kjente programmet (som kan være kryptografisk signert til å opprette en digital signatur eller alternativt lagret på en trygg måte) testes mot det aktuelle programmet som eksekverer. Problemet med å lage en hash-kode over hele programmet er at forskjellige forekomster av et legitimt program kan ha litt forskjellige avbildninger. Så en hash-kode som er beregnet på en måte som krever fullstendig identitet mellom det kjente programmet og den aktuelle forekomsten av programmet kan være for restriktivt. Fortrinnsvis utføres valideringen på en måte som sikrer at programmet er hva det er forutsatt å være, men som ikke er overdreven restriktiv, dvs. valideringsprosessen kan sammenlikne hash-koder av programkomponenter som er kjent til å være fast og kan utføre andre tester på programkomponenter som kan endres i løpet av tiden. Komponenten som utfører valideringen burde være skreddersydd til de spesifikke egenskapene av programmet som skal godkjennes; oppfinnelsen er ikke begrenset på en spesiell teknikk for å godkjenne et program.

Den andre delen av valideringen - dvs. å verifisere/sette maskintilstanden - er fortrinnsvis utført ved å sette alle relevante "kilder" av tilstanden til kjente verdier. Typisk kommer den relevant tilstanden som kan berøre et operativt program fra tre kilder: hovedprosessoren, brikkesettet og minnet. Ved tidspunktet for valideringen kan f. eks. hovedprosessoren settes i en kjent tilstand - f. eks. ring 0 med programtelleren satt til en kjent adresse, alle dataregistrene settes til null og all minne, bortsett fra minnet hvor lasteprogrammet er lagret, settes til null. Når lasteprogrammet har blitt verifisert å oppføre seg riktig når det eksekverer med maskinen i denne tilstanden burde kombinasjonen av å undersøke lasteprogrammet og å plassere maskinen i den godkjente tilstanden sikre riktig oppførsel frem til den tiden når innloggingsprogrammet 418 kjører. Som diskutert ovenfor er én av fordelene (enn om ikke den eneste) av riktig oppførsel opp til kjøringen av innloggingsprogram 418, at skadelige komponenter som ville forårsake at nøkkelen 204 ville bli frigitt på feil grunnlag, ikke lastes.

Det skal bemerkes at for at valideringsprosessen skal beskytte lastingen av operativsystemet mot skadelige komponenter, burde det være tilstrekkelig sikker at valideringsprosessen selv eksekverer korrekt. Riktigheten av valideringsprosessen kan sikres ved å utføre gyldighetsovervåkeren som en agent med tillitt som eksekverer på eller i et høysikkerhetsdatabehandlingsmiljø. For eksempel kan det være et lite operativsystem som utfører et begrenset sett av funksjoner, men som tilveiebringer en høy grad av sikkerhet som slike operativsystemer skal utføre i henhold til spesifikasjonene. Et slikt operativsystem kan eksekvere sammen med andre operativsystemer på en enkel maskin og isolasjonen av et slikt høysikkerhetsoperativsystem fra de andre (mindre trygge) miljøer på systemet kan vært påtvunget av en overvåkende komponent, så som en "hypervisor" eller virtuellmaskinmonitor (VM-monitor). (I én utførelsesform påtvinger en VM-monitor partisjoner som er miljøer som VM-monitoren vedlike-holder i en tilstand av gjensidig isolasjon fra hverandre, og hvor et operativsystem kan eksekvere.) Videre kan høysikkerhetskomponenten har eksklusiv tilgang til en tillitsbase, så som en maskinvaremodul som anvender og beskytter kryptogråfiske nøkler på plattformbasis. Gyldighetsovervåkeren kan være et program (eller "agent") som eksekverer i et slikt høysikkerhetsmiljø, som ville tilveiebringe sikkerhet at - i den utstrekning en kan stole på at høysikkerhetsmiljøet selv motstår angrep - gyldighetsovervåkeren ville ikke bli angrepet fra utenfor høysikkerhets-miljøet som ville forårsake at den oppfører seg uriktig. Som nevnt ovenfor kan høysikkerhetsmiljøet i tillegg tilveiebringe forseglet lagring (dvs. evnen til å lagre dataenheter og å frigi disse bare til et spesielt objekt som denne dataenheten er koblet til), og gyldighetsovervåkeren kan bruke det forseglede lager til å lagre nøkler som skal bli frigitt. Det skal bemerkes at gyldighetsovervåkeren kan være en integrert del av høysikkerhetsmiljøet, men kan også være en separat komponent som eksekverer i høysikkerhetsmiljøet.

Figur 5 viser et eksempel med en gyldighetsovervåker 550 som utfører validering i samsvar med prosedyren beskrevet ovenfor. Gyldighetsovervåker 550 har evnen å evaluere lasteprogram 410 på riktighet og/eller samsvar med et sett med kjente standarder. I tillegg har gyldighetsovervåker 550 evnen å evaluere og/eller påvirke maskinstatus 502. Ved å bruke kombinasjonen av disse evnene kan gyldighetsovervåkeren 550 sikre at lasteprogram 410 oppfører seg riktig ved å sikre at lasteprogrammet 410 er akkurat det lasteprogram som er forventet at det kjører og ved å sikre at maskinen som det eksekverer på, er i en tilstand hvor lasteprogrammet 410 er kjent for å oppføre riktig.

Strukturelt kan gyldighetsovervåkeren 550 innbefatte to komponenter: en generell del 504 og en lasteprogram-spesifikk del 506. Den generelle delen 504 omfatter kode som er felles til et stort mangfold av gyldighetsovervåkere (eller alle gyldighetsovervåkere). Den lasteprogram-spesifikke delen 506 omfatter kode som spesifikk relaterer til valideringen av et spesielt lasteprogram 410 - dvs. kode som forstår hvordan en legal forekomst av lasteprogrammet 410 (eller trinn 2 av lasteprogram 410) ville se ut og som utfører tester for å sikre at lasteprogram 410 over-holder denne forståelsen. Derfor kan den lasteprogram-spesifikke delen 506 kombineres med den generelle delen 504 for å danne en fullstendig gyldighetsovervåker.

Gyldighetsovervåker 550 er komponenten som ultimativ bestemmer om nøkkel 204 skal gis til lasteprogrammet (som så senere skal gi den til operativsystemet for bruk innenfor operativsystemet i samsvar med måten det er tillatt av et innloggingsprogram, som beskrevet ovenfor). Gyldighetsovervåker 550 kan beskytte nøkkel 204 ved å forsegle nøkkel 204 til gyldighetsovervåker 550 i en forseglet lagringsanordning 508. Den forseglede lagringsanordning 508 kan være et kjennetegn av et høysikkerhetsdatabehandlingsmiljø. Den forseglende lagringsanordning 508 kan tillate komponenter å eksekvere i et høysikkerhetsmiljø for å knytte vilkårlige data til seg selv, slik at ingen andre komponent kan få tak i disse data. For eksempel kan den lasteprogramspesifikke delen 506 av gyldighetsovervåker 550 knytte nøkkel 204 til seg selv. Den forseglende lagringsanordning 508 skal hindre alle komponenter bortsett fra den lasteprogramspesifikke delen 506 å bryte forseglingen av nøkkelen 204. Nøkkel 204 er da beskyttet fordi den bare kan hentes frem av den lasteprogramspesifikke delen 506 og lasteprogram-spesifikk del 506 vil bare distribuere nøkkel 204 til et lasteprogram som lasteprogram-spesifikk del 506 stoler på at det ikke er årsak for at nøkkel 204 blir frigitt på feil grunnlag. I en annen utførelsesform er nøkkelen forseglet basert på en kombinasjon av komponenter som innbefatter gyldighetsovervåkeren og trinn 2 av lasteprogram 410.1 en slik utførelsesform kan den lasteprogramspesifikke delen av gyldighetsovervåkeren 506 være fjernet fordi forseglingslagrings-mekanismen hovedsakelig selv sikrer tilstedeværelsen av et korrekt trinn-2-lasteprogram før forseglingen til nøkkelen brytes, siden binærfilen for et korrekt trinn-2-lasteprogram er del av grunnlaget for å lage forseglingen.

Eksempelprosess med å beskytte SYSKEY

Figur 6 viser en eksempelprosess hvordan en nøkkel beskyttes i samsvar med aspekter av oppfinnelsen beskrevet ovenfor. Et sted etter at en maskin er startet, utføres et operativsystemlasteprogram (602). Under utføringen av operativsystemlasteprogrammet godkjennes lasteprogrammet og maskinstatus

(604) for derved å sikre at lasteprogrammet oppfører seg på en forutsigbar måte pga det skrevet ovenfor. Etter at lasteprogrammet og maskinstatus har blitt godkjent brukes lasteprogrammet til å laste operativsystemet mens det forhindres at skadelige komponenter blir hentet (606). (Som diskutert ovenfor betyr validering av lasteprogrammet og maskinstatus at den fremtidige oppførselen av lasteprogrammet er kjent til ikke å resultere i nedlastingen av skadelige komponenter.) Etter at operativsystemet er lastet kjøres innloggingsprogrammet som styrer tilgangen til nøkkelen.

Andre eksempelutførelsesformer

Det skal bemerkes at mekanismene av foreliggende oppfinnelse ikke bare kan brukes til å utføre nedlastingen av et operativsystem men kan generelt brukes til å få et system til å utføre en funksjon i en "rå" (ikke-godkjent) tilstand mens det kreves validering for å fortsette med visse funksjoner. For eksempel kan en datamaskin utføre noen funksjoner uten noen slags validering. (F. eks. kan datamaskinen få lov til å virke som en radio, men valideringen må gjennomføres før datamaskinen kan utføre mer sensitive funksjoner - f. eks. lese filer fra plate-lageret). Generelt kan en maskin betraktes som både et husholdningsapparat og en generell PC og at husholdningsapparatdelen ikke krever validering/innlogging mens den generelle PCen gjør det.

Videre er gyldighetsovervåkeren ikke begrenset til enten å frigi/ikke frigi et spesielt sett av nøkler til innloggingsprogrammet men kan være konfigurert til å frigi spesifikke sett av nøkler til spesielle programvaregrupper - dvs. det finnes én programvaregruppe som kan få en første nøkkel, men gyldighetsovervåkeren kan frigi en annen nøkkel bare til en programvaregruppe som har blitt validert mer grundig.

I tillegg har nøkler ikke nødvendigvis behov for å bli frigitt gjennom en innloggingsprosedyre men kan heller være tilveiebrakt gjennom vilkårlige valideringsprosedyrer. For eksempel kan et binærprogram som avspiller DVD'er, få f eks utlevert DVD-funksjonsnøkler etter at gyldighetsovervåkeren har bestemt at spilleren er den legale binærfilen, og dette uten å kreve innlogging.

I tillegg kan noen programmer arbeide i én form uten validering, men kreve validering for å få lov å vise en annen spesifikk funksjonalitet. For eksempel kan telefonianvendelser starte uten innloggingskrav, men kan kreve innlogging før nøklene frigis som ville tillate at kryptografiske funksjoner kan brukes.

Det ble nevnt at foregående eksemplene har blitt tilveiebrakt bare til forklaringsformål og skal overhode ikke oppfattes som begrensende på foreliggende oppfinnelse. Mens oppfinnelsen har vært beskrevet med referanse til forskjellige utførelsesformer skal det forstås at dette heller er gjort som en beskrivelse og illustrasjon enn som en begrensning. Videre er oppfinnelsen - til tross for den har vært beskrevet her med referanse til spesielle hjelpemidler, materialer og utførelsesformer - ikke tenkt til å bli begrenset på de her fremlagde detaljene; heller strekker oppfinnelsen seg til alle funksjonelle ekvivalente strukturer, fremgangsmåter og bruk som er innenfor omfanget av vedlagte kravene.

Claims (30)

1. Et datamaskinlesbart medium kodet med datamaskineksekverbare instruksjoner for å utføre en fremgangsmåte, karakterisert vedat den omfatter: - å starte et operativsystemlasteprogram (602); - å validere identiteten eller riktigheten av lasteprogrammet (604); - å sikre at maskinen på hvilken operativsystemlasteprogrammet eksekverer, er i en kjent tilstand (604); og - dersom identiteten eller riktigheten av lasteprogram viser seg, og dersom maskinen hvor operativsystemet eksekverer er i en kjent tilstand, da: - tilveiebringe en nøkkel til lasteprogrammet (606); og - tillate lasteprogrammet å laste et operativsystem (606).

2. Maskinlesbart medium ifølge krav 1, karakterisert vedat fremgangsmåten videre omfatter å kjøre et innloggingsprogram som styrer tilgangen til nøkkelen (608).

3. Maskinlesbart medium ifølge krav 2, karakterisert vedat innloggingsprogrammet sikrer at en bruker tilveiebringer akkreditiver som en betingelse for at innloggingsprogrammet innrømmer tilgang til nøkkelen.

4. Maskinlesbart medium ifølge krav 1, karakterisert vedat nøkkelen kan brukes til å dekryptere en kryptert operativsystempartisjon.

5. Maskinlesbart medium ifølge krav 1, karakterisert vedat handlingen med å godkjenne identiteten eller riktigheten av lasteprogrammet og handlingen med å sikre at en maskin er i en kjent tilstand (604), er utført etter at alt av det følgende har blitt eksekvert: - et grunnleggende inn/ut-system; - en tilleggs-ROM; - et hovedoppstartsdatasett; og - en oppstartssektor.

6. Maskinlesbart medium ifølge krav 5, karakterisert vedat handlingen med å godkjenne identiteten eller riktigheten til lasteprogrammet og handlingen med å sikre at en maskin er i en kjent tilstand (604), er utført etter at en del av operativsystemlasteprogrammet har eksekvert.

7. Maskinlesbart medium ifølge krav 6, karakterisert vedat handlingen med å godkjenne (604) er utført etter at alt, eller i det vesentlige alt, av et operativsystem har startet, eller etter at noen av partisjonene har startet, hvor hver partisjon omfatter et miljø i hvilket noen grad av isolasjon fra andre partisjoner er oppretthold av en VM-monitor.

8. Maskinlesbart medium ifølge krav 1, karakterisert vedat nøkkelen er knyttet til en gyldighetsovervåker som utfører den godkjennende handling og den sikrende handling, og hvor fremgangsmåten videre omfatter at gyldighetsovervåkeren åpner forseglingen til nøkkelen.

9. Maskinlesbart medium ifølge krav 8, karakterisert vedat nøkkelen er knyttet til minst gyldighetsovervåkeren, og at gyldighetsovervåkeren godkjenner (604) minst en del av lasteprogrammet.

10. Maskinlesbart medium ifølge krav 8, karakterisert vedat nøkkelen er knyttet til gyldighetsovervåkeren og til minst en del av lasteprogrammet.

11. Maskinlesbart medium ifølge krav 1, karakterisert vedat maskinen omfatter en fysisk maskin.

12. Maskinlesbart medium ifølge krav 1, karakterisert vedat maskinen omfatter en virtuell maskin.

13. Maskinlesbart medium ifølge krav 12, karakterisert vedat nøkkelen bare blir frigitt dersom en arkitektur av den virtuelle maskinen ikke har endret seg eller er gyldig.

14. Maskinlesbart medium ifølge krav 1, karakterisert vedat handlingen med å sikre at en maskin er i en kjent tilstand (604) omfatter: - å evaluerende den løpende tilstanden til maskinen og sammenlikne den løpende tilstanden med den kjente tilstanden.

15. Maskinlesbart medium ifølge krav 1, karakterisert vedat handlingen med å sikre at en maskin er i en kjent tilstand (604) omfatter: - sette den løpende tilstanden til maskinen til å bli konsistent med den kjente tilstanden.

16. Maskinlesbart medium ifølge krav 1, karakterisert vedat lasteprogrammet er et helt operativsystem eller en hel forekomst av et operativsystem.

17. System for å utføre en oppstart av et operativsystem (134) under forhold som tilveiebringer sikkerhet i forhold til påliteligheten av oppstarten,karakterisert vedat systemet omfatter: - en gyldighetsovervåker (550) som evaluerer riktigheten eller identiteten til et operativsystemlasteprogram (410) som skal laste operativsystemet (134), og som videre evaluerer tilstanden til en maskin (502) på hvilken operativsystemlasteprogrammet (410) skal operere som enten tillater eller forbyr operativsystemlasteprogrammet (410) til å fortsette med å laste operativsystemet (134) avhengig av om riktigheten eller identiteten av operativsystemlasteprogrammet (410) er verifisert eller ikke, og som plasserer denne maskinen i en kjent tilstand (502) før den tillater operativsystemlasteprogrammet (410) å fortsette.

18. System ifølge krav 17, karakterisert vedat en nøkkel (204) er knyttet til denne gyldighetsovervåker (550) og hvori gyldighetsovervåkeren (550) åpner forseglingen til nøkkelen (204) og leverer nøkkelen (204) til operativsystemlasteprogrammet (410) dersom operativsystemlasteprogrammet (410) har lov å fortsette.

19. System ifølge krav 17, karakterisert vedat gyldighetsovervåkeren (550) evaluerer riktigheten eller identiteten til operativsystemlasteprogrammet (410) og evaluerer tilstanden av maskinen (502) etter operativsystemlasteprogrammet (410) har startet, men før operativsystemlasteprogrammet (410) har initialisert en kjerne (416) eller en driver.

20. System ifølge krav 17, karakterisert vedat gyldighetsovervåkeren (550) omfatter: - en generell del som er felles for en klasse av gyldighetsovervåkere; og - en spesifikk del som er spesifikk for operativsystemlasteprogrammet (410) og som kan erstattes med en annen del i tilfellet gyldighetsovervåkeren (550) brukes til å godkjenne et annet operativsystemlasteprogram (410).

21. System ifølge krav 17, karakterisert vedat maskinen omfatter en fysisk maskin.

22. System ifølge krav 17, karakterisert vedat maskinen omfatter en virtuell maskin.

23. Fremgangsmåte med å starte et operativsystem, karakterisert vedat den omfatter: - å eksekvere et grunnleggende inn/ut-system, en tilleggs-ROM, et hovedoppstartsdatasett og en oppstart sektor; - å starte et operativsystemlasteprogram (602); - å godkjenne operativsystemlasteprogrammet (604); - å godkjenne en tilstand til en maskin (604) på hvilken operativsystemlasteprogrammet eksekverer; - dersom operativsystemlasteprogrammet og tilstanden av maskinen er validert til å være rett, å tillate at operativsystemlasteprogrammet laster et operativsystem (606).

24. Fremgangsmåte ifølge krav 23, karakterisert vedat en nøkkel som er nødvendig for å utføre korrekt minst én funksjon under operativsystemet er knyttet til en gyldighetsovervåker som utfører handlingene med å godkjenne et operativsystemlasteprogram og å godkjenne en maskinstatus (604), og hvor fremgangsmåten videre omfatter: - dersom operativsystemlasteprogrammet og maskinstatus er gyldige, bryte forseglingen til nøkkelen og levere nøkkelen til operativsystemlasteprogrammet (606).

25. Fremgangsmåte ifølge krav 23, karakterisert vedat den videre omfatter: å eksekvere et innloggingsprogram etter at operativsystemet er lastet som styrer tilgangen til nøkkelen (608).

26. Fremgangsmåte ifølge krav 23, karakterisert vedat innloggingsprogrammet enten tillater eller ikke tillater komponenter av operativsystemet å bruke nøkkelen avhengig av om en bruker med suksess fullfører en legitimeringsprosedyre.

27. Fremgangsmåte ifølge krav 23, karakterisert vedat handlingene med å godkjenne operativsystemlasteprogrammet og å godkjenne maskintilstanden (604) er utført etter at operativsystemlasteprogrammet har utført minst én handling.

28. Fremgangsmåte ifølge krav 27, karakterisert vedat handlingene med å godkjenne operativsystemlasteprogrammet og å godkjenne maskintilstanden (604) er utført ved et tidspunkt før det å tilbakestille maskintilstanden vil hindre lasteprogrammet å fungere riktig når det laster operativsystemet.

29. Fremgangsmåte ifølge krav 23, karakterisert vedat maskinen omfatter en fysisk maskin.

30. Fremgangsmåte ifølge krav 23, karakterisert vedat maskinen omfatter en virtuell maskin.