SE531992C2 - Metod och system för säker programvaruprovisionering - Google Patents

Description

20 25 30 EEE nivån efter det att apparaten har tillverkats och förutsätter att den har levererats till kunden med betrodd programvara och att säkerheten inte har brutits vid något tillfälle under produktionsprocessen. Detta innebär att i tillverkningsstadiet är integriteten hos försörjningskedjan för produktion och distribution vitalt viktig, i synnerhet när det kan vara ett flertal oberoende entiteter inblandade i produktionskedjan.

Datorsystem och många konsumentelektronikprodukter levereras typiskt med på systemet förinstallerad driitprogramvara som gör dem fungerande direkt från förpackningen. Emellertid är det ibland så att programvarurevisioner och uppgraderingar utvecklas under produktionsprocessen av en separat utvecklingsgrupp som år lokaliserad i ett armat land och som har ett kontraktsmässigt outsourcing- förhållande med tillverkaren. Dessa outsourcing-förhållanden etableras ofta av kostnadsskäl där tillverkning sker på marknader med lägre arbetskraftskostnader.

Frågan om säkerhet och programvaruintegritet blir en viktig fråga för tillverkaren när det är ett flertal aktörer i försörjningskedjan. Ett exempel är det i vilket ett första företag som sin huvudprodukt har en programvarubaserad applikation (tillämpningsprogram) som tillhandahåller funktionalitet till en vanlig datorhårdvara, såsom en videospelskonsol eller en PBX (private bransch exchange - intern telefonväxel) som kör på en standard-PC-plattfonn. Programvaran kan vara utvecklad av utvecklaren i ett forsta land och sedan ha sänts till ett andra företag i ett andra land för tillverkning och sammansättning. l ett sådant arrangemang blir det av högsta vikt för programvaruutvecklaren, för det första, att de kan garantera integriteten hos programvaran, d.v.s. att ingen illvillig kod har införts under tillverkningsprocessen, och för det andra, att programvaran, som är den högvärdetillförande komponenten, inte blir illegalt kopierad eller piratanvänd vid den lägre änden av försörjningskedjan. Utan ett sätt att skydda programvaran skulle tillverkaren vara fri att klona och installera produkten på ytterligare hårdvamplattforrnar ”vid sidan om” eftersom den handelsvaruanpassade hårdvaran i allmänhet är den artikel med lägre kostnad (värde) som utgör en del av produkten.

Ett sätt att minska några av de ovannämnda problemen är att använda kryptering med öppen nyckel (t.ex. Asymmetrisk kryptering) som möjliggör verifiering av att en lO 15 20 25 30 I-.Tl Qi] ...a LE! F42* M programvanifilavbildning, såsom en operativsystemavbildning (OS-avbildning), är auktoriserad att nedladdas till en hårdvaruenhet. Algoritmer för elektronisk signatur med öppen nyckel kan användas för avsändarautentieering genom att elektroniska signaturer kan användas till att autentieera skaparen av programvaruavbildningen.

Skapandet av en digital signatur för en programvaruavbildning involverar typiskt beräkning av en modifikationsdetekteringskod for programvaruavbildniiigen. En ytterligare beräkning medelst en matematisk algoritm används till att 'fsignera” koden med en hemlig nyckel som är känd bara av skaparen av programvaruavbildningen. Den öppna nyckeln som motsvarar skaparens hemliga nyckel tillhandahålls allmänt åtkomligt för att autenticera avsändaren. Asymmetrisk kryptering tillåter den ursprungliga programvaruutvecklaren att kryptera en programvaruavbildning med sin egen hemliga nyckel och att sända den till en annan användare som kan dekryptera den medelst den motsvarande öppna nyckeln, vilket resulterar i en transaktion med hög säkerhetsnivå. Dessutom ger det en försäkring att skaparen (och ingen annan) hade sänt avbildningen utan att skaparen måste avslöja sin hemliga nyckel.

Utöver säkerhet involverar andra frågor som är viktiga för programvaruutvecklaren begreppen tillgänglighet och felsäkerhet eller motståndskraft mot fel. Termen ”tillgänglighet” används i denna text för att referera till förmågan att distribuera programvara eller programvaruuppgraderingar till ett stort antal enheter på ett ändamålsenligt och kostnadseffektivt sätt. Till exempel finns det ett behov för ett företag som gör det primära sarnmansättningsarbetet på datorhårdvaran att installera eller uppgradera programvara på kanske tiotusentals (eller fler) produktenheter utan att behöva ha supportpersonal för de individuella enheterna. Kostnaden för arbetskraften som krävs för individuell uppmärksamhet skulle i detta fall vara direkt hindrande, för att inte nämna den höga återkommande kostnaden varje gång det krävs en uppgradering eller när det förekommer funktionsfel i en programvara eller en hårdvara. Om dessutom produkten är drifisatt på fältet på en avlägsen plats skulle kostnaden för att sända supportpersonal för att ge den service vara mycket hög. Således finns det ett behov av att göra pro gramvaruinstallationer eller uppgraderingar ”tillgängliga” på ett säkert sätt för en stor mängd enheter utan att det krävs signifikanta mängder arbetskraft. 10 15 20 25 30 Begreppet “motståndskraft mot fel” används i denna text till att referera till förmågan hos enheterna att återhämtas fiån ett katastrofalt programvarufel. Det finns till exempel ett behov av förmågan att hantera en situation där programvaran hänger upp sig på grund av exempelvis fel i programkod (kodbuggar) eller korrupt data. Det krävs en lämplig mekanism som skulle möjliggöra för enheten att återhämtas och gå i drift igen under det att enheten är i drift på fältet, företrädesvis utan behov av signifikant arbete av servicepersonal.

Patentpublikationen US 2005/0138414 i namnet Zimmer et al visar en metod att lagra startaltemativ och integritetsiiiforination på en portabel extern enhet för användning i en för-operativsystemmiljö (före start). Vid start validerar datorsysternet en OS-avbildning med användning av en extern enhet innan den laddas för exekvering. Den extema enheten är avsedd vara ett manipuleringssäkert medium såsom ett smartcard eller en CD_ROM som tillhandahålls en behörig person för syftet att införas i datorn för att validera OS avbildningen. Den externa enheten, som införs under fasen före start, innehåller ett binärt objekt innehållande en öppen nyckel för bekräftelse av integriteten hos en OS-avbildning som laddas från en lokal masslagringsdisk eller laddas från ett nätverk. Dessutom kan personligt identifikatíonsnummer (PIN) och/eller en biometrisk sensor användas tillsammans med den externa enheten för utökad säkerhet.

Trots att proceduren som beskrivs i Zimmer-publikationen utvecklades för att tillhandahålla en högsäkerhetsmekanism för validering av OS-avbildningar genom en portabel personlig extern enhet, adresserar den inte frågan om ”tillgänglighet” i den meningen att valideringar på datorsystem i stora mängder inte är lämpliga när man använder personliga extema enheter. Detta är speciellt fallet om ytterliggare säkerhetsåtgärder såsom PIN-koder eller biometri-information måste matas in av ägaren av den externa enheten. Denna metod frarnkallar genom sina inneboende egenskaper en tradeoff mellan hög säkerhet och hög tillgänglighet eftersom den kräver närvaro av ägaren av den externa enheten till startfasen för programvaruinstallationer och uppgraderingar. Vidare saknas det verifiering av själva den externa enheten för att bekräfta att den är säker vid införandetillfället. Detta lämnar öppet för möjligheten att den externa enheten själv skulle kunna manipuleras och bli ineffektiv. Metoden är 10 15 20 25 30 3512 begränsad till miljön före start vilket innebär att BIOS, som finns i icke-flyktigt läsminne och är det första programmet som körs vid initialisering, typiskt utför några förhållandevis enkla initiala systemkontroller. BIOS innehåller bara några kilobyte av kod och har således inte förmågan att exekvera de mer komplexa typerna av Säkerhetspolicy som kan köras i miljön efter start.

BIOS utför några initiala kontroller på systemet och innehåller bara några kilobyte av kod, och har alltså förhållandevis begränsad förrnåga att möjliggöra mer komplexa typer av Säkerhetspolicy.

I betraktande av det föregående är det önskvärt att tillhandahålla en metod och ett system som tillhandahåller kontroll genom hela produktionskedjan på ett sätt som tillhandahåller säkerhet hos programvara samtidigt med hög tillgänglighet och motståndskraft mot fel på ett ändamålsenligt och kostnadseffektivt sätt.

Sammanfattning av uppfinningen Kortfattat beskrivet och i enlighet med utföringsformer och relaterade särdrag hos uppfinningen, tillhandahålls ett förfarande och ett system lämpliga för provisionering i stor skala av installation och hantering av programvara i datorenheter vilka har hög säkerhet och stor motståndskraft mot programvarufel. Uppfinningen kan anpassas för användning i online-, offline, och frikopplade (stand alone) situationer. I en utföringsforrn av uppfinningen är BIOS hos måldatorenheten anpassad så att den vid strömtillkoppling styr systemet att initialt starta från ett sekundärt medium på USB- porten, dvs. från en införd USB-minnessticka. BIOS har inom koden funktioner för implementering av en systembevakningsmekanism för försäkring av att systemet är i ett känt tillstånd, en funktion för verifiering av digitala signaturer, och laddningsdrivrutiner för filsystemaccessfunktionalitet för filbaserad access istället för den typiska startsektorbaserade accessen till en huvudstartpost (master boot record). USB-stickan, som kan vara vilken som helst portabel USB-kompatibel lagringsartikel som år kapabel filer såsom USB-flashminnen operativsystemavbildning (OS image) och relaterade startfiler, vilka var och en har att lagra eller MP3-spelare, inkluderar en 10 15 20 25 30 blivit digitalt signerade av avbildningsskaparen med användning av ett asymmetriskt krypteringssystem och med hans hemliga nyckel. Motsvarande öppna nyckel lagras på moderkortet hos enheten vid olika ett icke-flyktigt parameterminne, tillverkningstillfállet t.ex. på och kan ersättas av aktörer genom hela produktionsprocesssen eller vid kundnivån.

OS-avbildningen laddas in till systemet från USB-stickan bara efter lyckad verifiering av de digitala signaturema. Om verifieringen misslyckas, inkrementeras en "Dirty_USB"-räknare och systemet försöker göra ett antal omstarter (reboots) upp till ett förbestämt maximalt antal försök “USB_max”, efter vilka det försöker starta från det interna primärmecliet exempelvis ett compact flash-minne på moderkortet. Om OS- avbildningen på USB-stickan verifieras, laddas den in till systemet och ett kodhopp exekveras från USB-OS-avbildningen (om den primära OS-avbildningen är giltig och “ATB”-fiaggan är satt till ett) till en lämplig kärna hos det primära operativsystemet.

Hoppet är transparent och operativsystemet fortsätter att köra som om det hade körts fiån primärminnet.

Systemet är motståndskraftigt mot strömförsörjningsfel under programvamuppgradering av det sekundära USB-mediet, varvid tillståndet lagras i det programmerbara parameterläsminnet (programmable read-only parameter memory) och varvid bevakningsmekanismen säkerställer att systemets tillstånd är känt och annars startas det om (rebooted) till ett känt initialt tillstånd. Systemet startar om ett begränsat antal gånger tills det maximala antalet ”USßgmax” har uppnåtts, varvid det försöker starta från primärminnet. Om både primärmediet och sekundärmediet är korrupta, fortsätter omstartcykeln (reboot cycle) tills en giltig OS-avbildning påträffas, till exempel genom insättning av en ny USB-sticka i enheten. Med USB-stickan i förväg insatt möjliggör metoden praktiskt taget obevakade pro gramvamuppgraderingar eftersom det inte kräver något signifikant ingripande av supportpersonal. Säkerhet och tillförlitlighet upprätthålls genom hela produktionskedjan via användningen av digitala signaturer på avbildningsfilerna oavsett mediabärare och vem som hanterar den.

Kort beskrivning av ritningarna l0 15 20 25 30 Ešåll 952 Uppfinningen, tillsammans med ytterligare syften och fördelar därav, kan bäst förstås med hänvisning till följande beskrivning tillsammans med de medföljande ritningarna, i vilka: FIG. 1 och lA-IG är en översikt av systemarkitekturen i enlighet med en utföriiigsform av uppfinningen; FIG. 2 är ett blockdiagram av ett exemplifierande utvecklingssystem i enlighet med en utfóringsforrn; FIG. 3 visar ett flödesschema av en exemplifierande startprocedur enligt uppfinningen; FIG. 4 visar ett flödesschema som visar installatíonsmediamodulen för användningsfall både offline och online; FIG. Sa och 5b visar en exemplifierande process för Registerutgivningsansvarig hos Provisioneringspartnern; FIG. 6 visar konfigureringen av USB-stickan och parameterminriet vid tidpunkten för den forsta installationen; FIG. 7 visar ett exemplifierande arrangemang för provisionering online enligt föreliggande uppfirming; FIG. 8 är ett flödesdiagram som visar BIOS enligt föreliggande uppfinning; FIG. 9 visar de öppna nycklarna lagrade i parameterminnet och BIOS-nyckel lagrad i BIOS; FIG. 10 illustrerar den säkra startladdaren (secure boot loader) som finns i BIOS-flash såsom det är implementerat i utföringsforrnen; 10 15 20 25 30 *ri w mä FIG. l l visar en exemplifierande layout av startmediet; FIG. 12 visar en exempliñerande konfigurering av parameterminnet; FIGS. 13 och 14 är flödesscheman som illustrerar startproceduren for operativsystemet som firms på det sekundära mediet; FIG. 15 illustrerar ett exemplifierande sekvensdiagram for online-installationsscenariet enligt utfóríngsforrnen, och FIG. 16 visar ett exemplifierande tillståndsdiagram över Logistikservern enligt en utföringsforin av uppfinningen.

Detaljerad beskrivning av uppfinningen Föreliggande uppfinning beskriver olika utfóringsforrner som belyser olika aspekter av uppfinningen relaterande till säkerhetsprovisionering och tillgänglighet, vilka koncept är integrerade i den hela systemarkitekturen och genom hela produktionscykeln fór produkten. Provisioneringssystemet möjliggör ijärrinstallation och tjärruppgraderirig av programvara fór plattformar kopplade till ett flertal klasser av tillämpningar som relaterar till användningsfall for online-systern, trådanslutna system, trådlösa system och oñline-system. De mest detaljerade utfóringsforrnerna här avser det IBM-kompatibla PC-systemet, som kör ett kämbaserat operativsystem (kemel based operating system) såsom Linux eller WindowsTM, men uppfinningen kan modifieras för användning i andra datorarkítekturer och operativsystem.

I enlighet med uppfinningen är arkitekturen implementerad på ett flertal systemnivåer inklusive hårdvaru- och programvarukomponenter, krav och administrativa rutiner.

Komponenterna inkluderar ett Mål (Target), Bastionsserver (Bastion Server), Server, och Extemt startmedium (External boot media). Målet definieras som den systemenhet som hyser den säkerhetshanterade plattformen såsom beskrivs i denna diskussion. 10 15 20 25 30 gr: '33 .ä LD ILÜ M Bastionssewern definieras som en online server som hyser krypteringsnycklar in en högsäkerhetsniiljö. Servem definieras som en server som används till att hysa en funktion som behövs i supportinfirastrukturen. Det sekundära startmediet är vanligtvis ett portabelt lagringsmedium såsom en USB-flashminnessticka/-enhet eller en USB- minnesdiskenhet, vilka används till att tillhandahålla ett billigt medium för altemativa startproeedurer som är viktiga för att ge datorer hög tillgänglighet. USB-stickan används också till att utbyta data med Bastionsservrarna eftersom bastionen signerar avbildningen (image) och nätverket har relativt stor latens. Andra typer av USB-stickor som används i detta dokument är Överföringsstickor, lnstallationsstickor, Återställningsstickor och Fabrikskonfigurerade stickor.

För storskaliga produktionsmiljöer delegeras de olika uppgifterna i provisioneringskedjan till diverse olika aktörer. I den tidiga utvecklingsfasen utför samma aktör alla uppgifter. Samma teknologi används oberoende av skalan hos projektet där skillnaden ligger i fördelningen av funktionalitet bland hårdvara och de administrativa rutinerna.

Vi introducerar nu en utvidgning till konceptet med aktörer som är involverade i implementeringen som definieras enligt följande. Det skall noteras att inte alla aktörema är nödvändiga för att implementera uppfixmingen, varvid inkluderandet av någon individuell aktör kan bero på den specifika tillämpningen.

BASPROGRAMVARUUTVECKLARE aktör paketeringsverktygen Denna är ansvarig för detaljutforrnning av operativsystemet och såsom mailservrar, relationsdatabaser etc. till ett programvarupaket. Basprogramvaran hanteras typiskt av en monolitisk avbild (monolithic image) eftersom det kan firmas många beroenden mellan hårdvara och de olika programvarumodulerna som ingår i paketet.

Ett exempel är MMX-grafikmotorn som är inkluderad i en del processorer. Detta kan användas till ekokancellering i t.ex. en telefonapplikation, men kärnan måste l0 15 20 25 30 10 skräddarsys och PBX-applikationen som kör ovanpå kärnan måste vara medveten om detta. Å andra sidan bör grafik avlägsnas för att reducera fördröjningar i syfte att undvika avbrott i röstsignalen. Exemplet illustrerar beroendena inom basprogramvaran och behovet av att hantera basen som en monolit.

TJÄNSTEPROGRAMVARUUTVECKLARE Ett alternativ till att ha alla programvarufunktioner i en monolitisk basprogramvaruavbildning är att hantera funktionerna individuellt som tjänster.

Tjänsten integreras i provisioneringssystemet i alla aspekter of processen.

Provisioneringssystemet inkluderar en utvecklingsmiljö med stöd för många plattformar och uppbyggnadssystem som skapar signerade och krypterade avbildningar för massdrifisättniiig.

Programvaruutvecklaren är ansvarig för utvecklingen av applikationen och användandet av uppbyggnadsmiljön till att skapa avbildningar för Målenheterna. Uppbyggnadsmiljön är baserad på ett traditionellt system med tillägg för provisionering.

UTGIVNINGSANSVARIG Trots att en nyutvecklad programvaruavbildning kan ha passerat de olika validitetstesterna, finns det ett behov av en oberoende aktör, den Utgivningsansvarige, till litt godkänna utgivningen av avbildningen till produktionssystemet. Den Utgivningsansvarige är ansvarig för alla operationer som relaterar till Bastions-CA- servern som hyser de känsliga kryptografiska nycklarna. Till exempel, eftersom utveckling och produktion är olika i de flesta aspekterna, överlämnas de testade basprogramvaruavbildningarna och tjänsteprogramvaruavbildningarna till den Utgivningsansvarige som använder sin Utgivningsansvarighetsnyckel (Release officer Key) (ROK) till att skapa ett signerat anrop (request) mot en högsäker Online CA- server, som tillämpar Startproduktionsnyckeln (Boot production Key) (BPK) för basavbildningarna och Tjänstenyckeln (Service KEY) (SK) för tjänster. 10 15 20 25 30 ll TILLVERKARE Tillverkaren är ansvarig för övervakning av att provisioneringssystemets krav gentemot hårdvaruförsäljaren manifesteras i test- och konfigureringsservem som är lokaliserad vid slutet av sammansåttningslinjen. För varje produktionssats finns det ett manifest som kontrollerar alla tester och konfigurationer. Säkerhet är alltså integrerad i denna procedur. Om målet innehåller ett RSA-chip (såsom ett Atmel AT97SC3202-chip) kommer det att initieras och den öppna delen av nyckeln kommer att extraheras fiån chippet, annars kommer serienumret att skrivas till ett icke-flyktigt minne som typiskt är en del av moderkortet.

LOGISTIKPARTNER Eftersom ledtiden i härdvaruproduktion ofla är mer än 10 veckor och kanske inte matchar marknadskraven, måste produktionen göras i en storsatsprocess och sändas till en Logistikpartner. Dyra standardkomponenter såsom datorniinnen kan köpas baserat på bekräftade beställningar. Logistikpartnem och tillverkaren kan vara en och samma aktör beroende på fórtroendenivån.

PROVISIONERINGSPARTNER Provisioneringspartnem tillhandahåller utvecklingssystemet såsom programvaran för bakgrundsservrarna som behövs fór och tillhandahåller provisioneringen hårdvarukraven för målet.

IN STALLATIONSPARTNER En Installationspartner används till storskalig programvarudriftsättning med stora bandbreddsresurser och med högtillgänglighetsservrar, varvid en ISP typiskt används till att hysa installationsservem.

APPLIKATIONSÄGARE 10 15 20 25 30 12 Applikationsägaren är kunden till provisioneringssystemet och är någon som kan ta rollen av vilken som helst av de tidigare beskrivna aktörerna. Den exakta rollen hos Applikationsägaren är typiskt baserat mer på aftärsöverväganden snarare än på tekniska frågor.

KRYPTONYCKLAR Följande definitioner för kryptonycklar används i den följande diskussionen. Det skall noteras att alla nycklar inte är nödvändiga fór implementering av uppfinningen, varvid användningen av någon individuell nyckel kan bero på den specifika tillämpningen.

Flera typer av nycklar som var och en tjänar ett specifikt syfte ingår i uppfinningskonceptet. 0 Personlig identitetsnyckel, associerad med fysiska personer, utgivningsaiisvarig (RoK). 0 Tillfälliga nycklar, som används till registrering och uppsättning av CA system (CRK). 0 Apparatidentitetsnycklar, som används till säker kommunikation (TK). 0 Programvarunyckel, som används till signering och verifiering av programvara (BBK, BPK, sk, IK).

STARTUTVECKLINGSNYCKLAR (BOOT DEVELOPMENT KEY) (BDK) BDK:ama används i den tidiga utvecklingsfasen i en typiskt skyddad miljö i vilken ingen policy för säkerhetsansvarig tillämpas. Nycklarna är unika fór varje utvecklingssysystem så skadan blir begränsad om den hemliga nyckeln oavsiktligt exponeras.

KUNDREGISTRERINGSNYCKLAR (CUSTOMER REGISTRATION KEYS) (CRK) 10 15 20 25 30 Éšíšíl 33.2* 13 CRKIn genereras av Provisoneringspartnem och lagras i en bastionsserver som fifaktas till Applikationsägaren som en del av utvecklingssystemet. Ett primärt syfie med CRK- nyckeln är att autenticera och särskilja Kundutgivningsansvarig och Provisioneringspartner. Efter en lyckad registrering kan nyckeln kasseras från Bastionen och inte användas igen.

STARTPRODUKTIONSNYCKLAR (BOOT PRODUCTION KEYS) (BPK) De öppna nycklarna lagras på målenheterna och används till att verifiera den första avbildningen som laddas fiån extemt minne. Alla avbildningar måste signeras med den motsvarande hemliga nyckehi. Om den hemliga nyckeln komprometteras kan säkerheten hos alla målenheter som innehåller den motsvarande öppna nyckeln förloras.

På grund av vikten av att hålla den hemliga nyckeln säker lagras den i en offlinestående Bastionsserver med hög säkerhetsnivå. Utgivningsansvarig är typiskt ansvarig för att upprätthålla säkerheten hos den hemliga nyckeln.

UTGIVNINGSANSVARIGS NYCKLAR (RELEASE OFFICER KEYS) (ROK) Såsom tidigare har nämnts används ROK till att godkänna en programvaruavbildning för provisionering. Nyckeln kan användas till att signera en installationsavbildning genom BIOS-produktionsnyckeln eller till ladda upp en avbildning till installationsservern för framtida mass-spridning.

INSTALLATION SNYCKLAR (INSTALLER KEYS) (IK) IK-nycklarna används till att etablera förtroende mellan målenheten och provisioneringssystemet innan målet förvärvar ett eget X509-certifikat. Förutom de öppna nycklarna, får installationsmålenheten ta emot ett certifikat utfärdat av den CA som genererade lnstallationsnycklarna. Ett andra par av nycklar signerade av samma utfärdare används i installationsscenariet för online-miljö.

MÅLIDENTITETSNYCKLAR (TARGET IDENTITY KEYS) (TK) l0 15 20 25 30 14 TK-nycklarna genereras efter det att en lyckad installation har slutförts på mälenheten och sänds tillsammans med CA-certifikaten till Applikationsägarens OM-server.

TJÄNSTENYCKEL (SERVICE KEY) (SK) Denna nyckel genereras för varje uppsättning av tjänster som definierar en programvaruutgåva. Syfiet med nyckeln är att säkerställa integriteten hos programvaruutgåvan och tjänsten. Användningen av asymmetrisk nyckel-teknologi medger också att målenheten kan verifiera att utfärdaren av tjänsten är autenticerad.

Under utveckhngsfasen är utvecklaren tillåten att signera tjänster utan att involvera den Utgivningsansvarige. Emellertid kan basprogramvaran för en produktionsutgåva innehålla en annan nyckel som kräver involvering av den Utgivningsansvarige. svsTEMövERsiKT FIG. 1 visar en översikt av systemarkitekturen som avbildar servrar till stöd för online- provisioneringssystem, vilka fungerar i enlighet med en utfóringsform av uppfinningen.

Applikationsägaren 100 i denna utfóririgsforrri är kunden till provisioneriiigssystemet.

Inom utvecklingsmiljön 102 används systemen tillhörande Bastion l, Bastion 2, Installationsservem, och Testmålet under utveckling, där alla funktioner som behövs för småskalig produktion är installerade på ett fåtal servrar. Produktionsmiljön ll0 innehåller servrar som behövs av en värdpartner 120 i en fullskalig produktionsmiljö.

Ytterliggare två servrar 130 och 140 hanterar den initiala installationen och äterställning av system. De kan tillhöra antingen Applikationsägaren eller en Värdpartner.

Ytterliggare servrar inkluderar hårdvarutillverkaren 130 och kundservem 140. Vid slutet av produktionslinjen finns det en server till att konfigurera och testa enheten enligt ett fördefinierat testmanifest. Systemet lärnnas sedan vidare till kunden via en Logistikpartner som gör den slutliga sammansättningen av enheten innan den sänds vidare till kunden. Detta är ett sätt att reducera nödvändigheten av att ha dyra komponenter i lager eftersom det ofia är mer ekonomiskt att köpa standardkomponenter 10 15 20 25 30 15 efter det att en fast beställning har mottagits. Ur säkerhetsperspektivet kan Logistikpartnem vara ansvarig för hanteringen av kryptografiska nycklar. Den andra rollen som Logistikpartnem spelar är den av en mellanhand för att upprätthålla fabriken.

Logistikpartnern spelar en viktig roll är ett flertal applikationer definierade hos kunden, konfidentialiteten hos installationsbaskunden gentemot Även om såsom installation, programvarufel och hårdvaruutbyte.

FIG. lA visar en högre nivå av den infrastruktur som behövs för att stöda provisionering som inkluderar klusterkonceptet. Utvecklingsklustret innehåller ett srnåskaligt fullt fimgerande provisioneringssystem. Utvecklingsklustret innehåller alla fimktioner som behövs i en produktionsmiljö distribuerade på ett begränsat antal datorenheter. Nycklama som används under utvecklingscykeln tillhör en arman domän än nycklama som används i produktionen. Tanken är den att provisionering introduceras tidigt i produktens livscykel.

Kommunikationsparadigmet för klusterarrangemanget är den hos en multicast- meddelandebus (multicast message bus). Den används både intemt inom en värddator och externt mellan värddatorer. Alla externa kommunikationer krypteras och autenticeras och ramverket skriver tre typer av data på bussen, såsom visas i FIG. IB.

FIG. lC är ett diagram över en exemplifierande distributionsmotor som fungerar i enlighet med uppfinningen. Servern matchar den utgivna programvaran med målenheter. En felmatchning av hårdvaru-/programvaruversioner undviks genom att hämta data från det logistik-/installationskluster som är ansvarigt för respektive målenhet.

FIG lD-F visar exemplifierande diagram över Logistikklustret, Installationsklustret och Serviceklustret. Logistikklustret är en samling servrar som är ansvariga för installering av programvara för offline-provisionerade mål, samt för generering och installering av identitetscertifikat för varje offline-provisionerad enhet. Proxyservern för offline- används till återställningsrutiner och meddelanden uppgraderingar och administreringsdata på de offline provisionerade enheterna. 10 15 20 25 30 I! m! .az ILÛ LD M 16 Installationsklustret är en samling servrar som är ansvariga for installering av basprogramvaran for de online provisionerade målenhetema och for generering och installering av identitetscertiflkat fór online-provisionerade enheter utan kryptografiska moduler. for online- Det genererar och installerar också identitetscertifikat provisionerade enheter utan kryptografiska moduler.

Serviceklustret är en samling servrar som är ansvariga för installationstjänster fór provisionerade målenheter och tillhandahåller en spegel av konfigurationen hos den provisionerade enheten. Den bevakar också tillståndet hos målenheten och associerade tjänster.

En fabrikskonsolenhet är placerad vid slutet av sammansättningslirijen och utför en test och konfigurering av moderkortet. Varje nätverksgränssnitt tilldelas en MAC-address från konsolen varvid konsolen har förmåga att kommunicera genom att sända meddelanden antingen i online- eller offline-mod.

SIGNERING Av PRoGRAMvARUUrGÅvA (soFrwARE RELEAsE SIGNING) I ett storskaligt provisioneringssystem kan en dålig OS-avbildning påverka ett stort antal målenheter eftersom misstaget propageras i stor omfattning. Det finns ingen riktigt enkel lösning på detta problem eftersom det inte är lätt att blockera avbildningama som innehåller defekt kod. De flesta utvecklarna har resignerat infor det faktum att all programvara vanligtvis innehåller en del buggar och det är klokt att ha effektiva procedurer for att hantera dem, såsom detektering av problem, utförande av prograrnrättelser i koden (patching the code) och snabb utgivning av uppdaterade versioner.

FIG. 1G visar en exemplifierande procedur för signering av programvaruutgåvor i enlighet med en utíöringsform av uppfinningen. En Testansvarig är introducerad som en tullkontroll mellan utvecklaren och den Utgivningsansvarige. Bastion CA innehåller 10 15 20 25 30 17 Produktionsstartnyckeln (Production Boot Key) och kan konñgureras till att signera endast om båda ansvariga har signerat signeringsbegäran. Det finns emellertid en begränsning hos detta arrangemang i och med att detta sätter en del restriktioner på formatet hos en del data som används iorganisationen.

SÄKERHETSSTART AV UTVECKLINGSSYSTEM (SECURITY BOOTSTRAP OF DEVELOPMENT SYSTEM) Provisioneringssystemet är utformat att göra övergången från småskaligt pilotprojekt till fullskalig produktion smidig och säker. Säkerhet är hömstenen hos provisionering och således måste en välgenomtärrkt Säkerhetspolicy implementeras som en del av den övergripande arkitekturen. Det finns ett förhållande av ömsesidigt förtroende mellan Provisioneringspartnem och Applikationsägaren. Applikationsägaren måste ha full kontroll över nyckeln som signerar de programvaruavbildningar som målet verifierar under den tidiga startproceduren. Applikationsägaren måste också vara i säker besittning av den nyckel som godkänner avbildningar för provisionering. Tillverkaren måste också ha en stark autenticeringsmetod vid expediering av en provisioneringsbegäran som involverar ett stort antal målenheter. Under utveckling kan procedurerna för test och Utgivningsansvarige utelämnas.

En exemplifierande order på ett utvecklingssystem kan inkludera en order från Applikationsägaren till Provisioneringspartnern som bland annat inkluderar en email till kundens orderbekräftelse, överenskommelse och signerad Utgivningsansvarige, vilka alla behövs för att slutföra transaktionen.

FIG. 2 visar ett blockschema över ett exemplifrerande utvecklingssystem i enlighet med (kunden till Provisioneringspartnern) tar emot utvecklingssystemet med allting fórkonfigurerat att en utföringsforrn av uppfinningen. Applikationsägaren arbeta i en frikopplad miljö (standalone environment). Provisioneringspartnem förbereder utvecklingssystemet och genererar Utvecklings-BIOS-nycklarna (Development BIOS Keys) (BDK) fór att möjliggöra för nyckelinnehavaren att ändra BIOS till att tvinga datorsystemet att starta från det externa mediet som den förinställda 10 15 20 25 30 18 åtgärden (default action), till exempel från USB-stickan. Dessutom är BIOS-koden pro grainmerad att verifiera OS-avbildningen på USB-stickan med användningen av den öppna nyckeln. Den hemliga BDK-nyckeln är placerad i Bastion-l medan den öppna BDK-nyckeln laddas in i uppsättningen av måldatorer. Det slutliga steget är att generera kundregistreringsnycklar (customer registration keys) (CRK) så att kunden kan ta kontroll över måldatorn.

Kompileringsservern läser specifikationsfiler som styr vilka programpaket som skall kompileras. Utdata är en avbildning tillsammans med en signaturbegäran som skrivs till en USB-sticka. Nästa steg är att införa USB-stickan i Bastionvärddatom som är förkonfigurerad av Provisioneringspartnem. Installationsavbildningen införs i installationsservern, som verifierar avbildningen mot den i servern förinstallerade öppna BDK-nyckeln. USB-stickan med startavbildningen införs sedan i måldatom och lärnnas där så att BIOS vid varje omstart förinställt (by default) styr till att läsa från USB- stickan. USB-stickan kan införas i enheten före distribuering eller, i fallet av offline- uppgradering, kan USB-stickan som innehåller uppgraderingen helt enkelt införas för att ersätta den föregående och därmed möjliggöra på det hela taget ”obevakade” uppgraderingar efiersom det inte krävs någon ytterliggare inblandning av supportpersonal.

Det BIOS som tillhör föreliggande uppfirming inkluderar ytterliggare funktioner inom koden som inkluderar en bevakningsmekanism, signaturverifieririgsfunktion och drivrutiner för filsystemaccessfunktioner fór ñlbaserad access snarare än den typiska huvudstartposten (master boot record) som utför access startsektorbaserad access.

Bevakningsmekanismens roll är att säkerställa att systemet arbetar i ett känt tillstånd och om så inte är fallet att systemet styrs till att starta om.

När mäldatorn får strömtillslag styr BIOS den till att kontrollera förekomsten av en införd USB-sticka. Det skall noteras att det är möjligt att programmera BIOS till att kontrollera förekomsten av annat extemt medium, men i denna utföringsform är i allmänhet USB-porten den mest praktiska på grund av spridningen av USB-baserade lagringsmedier som mycket billiga handelsartiklar, för att inte nämna utbredningen av 10 15 20 25 30 19 MP3-spelarartiklar med förmåga att lagra filer vilket således gör dem idealiskt lämpade till lagring av filer.

FIG. 3 visar ett flödesschema över den exemplifierande startproceduren enligt utföringsforrnen. Den beskrivna proceduren är kapabel att undvika situationen där måldatorn hänger upp sig när en defekt USB-sticka har införts i USB-porten. Måldatom håller reda på hur många startförsök som har gjorts. Om antalet försök är färre än ett maximalvärde (t.ex. fem försök), såsom visas i steg 310, sätts ”Dirty_USB”-räknaren 320 och bevakningsmekanismen 330 sätts på en tillräckligt lång tid för att detektera huruvida systemet är i ett okänt tillstånd såsom 300 sekunder, och antalet försök i räknaren inkrementeras med ett. Signaturen hos OS-filen kontrolleras med avseende på validitet i steg 340, om den inte verifieras får processen feltillstånd vid steg 350, efter vilket systemet försöker starta om igen från steg 300. Om signaturen verifieras laddas startavbildningarna och målenheten börjar exekvera OS-avbildningen på USB-stickan.

När startavbildningen som finns på USB-stickan exekveras börjar den med att hindra bevakníngsmekanismen att återställa målet. Om tillståndet hos systemet är korrekt, dvs. att Startförsökräknaren (Atternpt_Tov_Boot counter) "ATB = O", börjar installationsproceduren. Slutligen återställs ATB-räknaren till noll för att motsvara det nya tillståndet hos målet och systemet startas om.

FIG. 4 är ett flödesschema som visar en installationsmediamodul som representerar en liten applikation som hanterar användningsfall både offline och online. Om installations-OS-avbildningen är lokaliserad på USB-stickan hämtas den från denna artikel, annars etableras en ömsesidigt autenticerad och krypterad session mot installationsservern så att installations-OS-avbildningen överförs strömmande från servern, vilken är verifierad. Signaturfilen som har skrivits av Bastionsservern verifieras i offline-mod när filen finns på USB-stickan eller när installationsavbildningen laddas från installationsservern.

FIG. Sa och 5b visar en exernplifierande process för den Registerutgivningsansvarige vid Provisioneringspartnern i enlighet med uppfinningen. Vid detta stadium har 10 15 20 25 30 20 utvecklaren lyckats bygga en målenhet som är redo för provisionering. Nästa sats av målenheter innehåller en annan startnyckel än den nyckel som fmns i de tidigare levererade målenheterna. Applikationspartnem måste begära av försäljaren av målenheter att använda sin egen hemliga nyckel till att signera den nya installations-0S- avbildningen. Det är viktigt att försöka reducera säkerhetshot så mycket som möjligt eftersom en provisioneringspartner också kan arbeta samtidigt med konkurrenter till Applikationsägaren.

Den hemliga delen av nycklarna, som tillhör Applikationsägarens Utgivningsansvarige och Produktionsstartproceduren, exponeras inte utanför de två Bastionsservrarna. Därför måste Applikationsägaren generera dessa två nycklar. Provisioneringspartnern måste ha en metod för att associera dessa två nycklar med en existerande kund. The Bastion-1 som har förberetts av Provisioneringspartnern innehåller en specialnyckel för detta ändamål (CRK).

Från och med detta är Applikationspartnem kapabel att beställa målenheter i stora volymer från Logistikpartnern. Installations-OS-avbildningen signerad av tillverkaren av målenheterna möjliggör för Applikationsägaren att ersätta de öppna nycklarna i parameterrninnet (BPK-hw) med sin egen (BPK-c) kundnyckel och därigenom möjliggöra för kunden att ha fullständig kontroll över enheten och att stänga ut alla andra. Parametermirinet (BPK-hw) är ett icke-flyktigt minne såsom flash eller EEPROM som typiskt finns lokaliserat på enhetens moderkort och konfigurerat att lagra nycklar. lnstallations-OS-avbildningen måste implementeras så att denna nyckelersättning görs innan installations-OS-avbildningens signatur verifieras på USB- stickan.

FIG. 6 illustrerar konfigurationen hos USB-stickan och hos målenhetens parameterminne vid tidpunkten för den törsta installationen i målenheten som levereras med startnyckel (boot key) tillhörande hårdvaruförsäljaren. Den första OS-avbildningen som laddas fi°ån USB-stickan är start-OS-avbildningen och dess signatur verifieras mot hårdvaruförsäljarens öppna nyckel som är lagrad i parameterminnet lokaliserat på moderkortet. Startavbildningen (boot image) signeras med försäljarens hemliga nyckel 10 15 20 25 30 21 som tillåter den att ta kontroll över målenheten. Innan ínstallations-OS-avbildningen laddas ersätts BPK-hw med Applikationsägarens egen nyckel (BPK-c), efter vilket installations-OS-avbildningen kan laddas.

USB-stickan kan stanna kvar i USB-porten för att tjäna som startväg för återställning.

Eftersom nyckeln som verifierar denna avbildning byttes ut måste signaturen också bytas ut. Startavbildningen måste implementeras så att den läser nyckeln från parameterminnet först för jämförelse med kundnyckeln, varvid den vid en skillnad mellan nycklarna åstadkommer att kundnyckeln återskrivs till parameterminnet. Detta tillåter att samma OS~avbildning signeras av tvâ nycklar och möjliggör utbyte av signaturfilen. Det är en föredragen operation att läsa 'från flashminne framför att utföra skrivoperationer eftersom en del typer av återskrivbara minnen typiskt har ett begränsat antal skrivcykler som kan läsas tillförlitligt.

ONLINE-PROVISIONERING FIG. 7 visar ett exemplifierande arrangemang för tillhandahållande av online- provisionering av OS-startavbildning i enlighet med föreliggande uppfinning.

Separeringen av startavbildning och installationsavbildning i offline-fallet kan enkelt modifieras för användning till online-provisíonering. Såsom ett exempel kan det vara önskvärt att återställa vissa målenheter från programvarufel genom omstartning över en online-anslutning. En Intemet-baserad (Secure Socket Layer) SSL-anslutning av standardtyp kan uppfattas som en säker utvidgning av signaturveriflering av installations-OS-avbildningen. Här verifieras installations-OS-avbildningen mot samma nyckel som finns i parameterminnet på målenheten. SSL-anslutningen är unik för varje installationsavbildning och tillhandahåller fördelen av att kontrollera att anslutningen görs med avseende på en specifik server. Metoden tillåter strömmande överföring av avbildningen över SSL-anslutningen och möjliggör därigenom förhållandevis snabb installation av mycket stora hårddiskar på målenheterna.

BIOS-FUNKTIONALITET 5 l0 15 20 25 30 22 FIG. 8 är ett flödesschema som illustrerar funktionaliteten hos ett BIOS som fungerar enligt en utföringsforni av föreliggande uppfinning. I standarddatorer är BIOS ett lager av systemresident kod som tjänar som ett operationellt gränssnitt mellan operativsystemet och hårdvaruenhetema för att tillhandahålla kompatibilitet mellan programvara och hårdvara. Ett BIOS enligt uppfinningen är anpassat att utföra ytterliggare uppgifter som möjliggör säker provisionering in form av OS- avbildningsverifiering och återställning i fall av systemfel.

När systemet först strörnsätts utför den en normal Självtest vid strömtillslag (power-on self test), vilket är standardproceduren för de flesta datorerna. Den kontrollerar sedan om det firms ett andra startmedium (t.ex. en USB-sticka) närvarande i en USB-port.

Innan den startar fi-ån USB-stickan kontrollerar den antalet gånger den tidigare har försökt starta från USB-stickan, i vilket fall parametem ”Dirty_USB” vid varje (misslyckat) försök inkrementeras med ett. Om denna parameter överskrider ett fórbestämt antal ”USB_max” kommer den att avbrytas och försöka starta fi~ån det primära mediet, exempelvis ett återskrivbart minne i form av ett Compact Flash på moderbordet. BIOS såsom det har implementerats iuppfinningen innehåller stöd för ett filsystem som eliminerar behovet för medier som är speciellt formaterade medier på sektorbas. Om exempelvis filsystemet är Linux VFAT som är kompatibelt med Windows långa filnamn på filsystemet FAT, kan vilket som helst kompatibelt portabelt minne såsom en MP3-spelare användas till att bära de tre startfilerna som krävs av startproceduren. Varje fil är digitalt signerad med en asymmetrisk hemlig nyckel som motsvarar den öppna nyckeln som är lagrad som en integrerad del av moderkortet. Om signaturen för alla filerna verifieras fortsätter proceduren till fas två, dvs. att ladda in ett operativsystem. lnnan styrningen överlämnas till det nya systemet, sätts bevakningsmekanism igång och parametern ”Dirty_USB” inkrementeras.

Uppfinningens BIOS skiljer sig från det i en standard-PC i det att en bevakningsmekanism är implementerad i startfasen.

Om inga sekundära medier detekteras, dvs. att ingen USB-sticka finns på plats, försöker systemet starta från det primära mediet (exempelvis Compact Flash-mediet). Genom att alltid först försöka starta från det sekundära mediet, kan lösningen utvidgas till att täcka 10 15 20 25 30 23 ett offline-system med funktionalitet for en räddningsstartprocedur. Om systemet har ett giltigt okorrupt prirnärrnedium installerat, kommer det alltid att försöka starta från sekundärt medium. Detta betyder att staftproceduren eventuellt måste återvända till att köra operativsystemet från primårmediet för att stabil systemexekvering skall uppnås.

I det osarmolika fallet där både det primära och det sekundära mediet är korrupta, kommer både parametem ”Dirty_USB” och parametem ”Dirty_cf° för oren compact flash slutligen att nå det maximala törbestämda värdet ”USB_max” (eftersom de flerfaldiga försöken till återstart kommer att misslyckas), vilket kommer att återställas till noll och därmed tillåta fortsatta startförsök. Huvudsyfiet är att tillåta operatören tillfället att föra in ett giltigt medium som innehåller okorrupt startbar programvara i det fallet att inget av medierna år startbara.

Genom introduktionen av uppsättningen parametrar för ”max” och ”dirty” rclaterande till det sekundära mediet, är systemet motständskraftigt vid fallet med strömbortfall exempelvis under en uppgradering av programvara på det sekundära mediet. Det enda kritiska området som finns år uppgraderingen av BIOS, men det kan emellertid undvikas genom att använda en skrivhinderoperation for skrivning till BIOS-minnet eller genom att sätta en bygelkoppling till läsminnet.

För verifieringsprocessen involverar verifieringsalgoritmen en asymmetrisk öppen nyckel. Det kan finnas åtskilliga nycklar som testas i följd, exempelvis lagras de forsta nycklarna i ett separat minne, och andra nycklar lagras i själva BIOS, i ett statiskt dataområde hos BIOS, för verifieringsändamål. Det är möjligt att producera ett kund- BIOS med en annan nyckel än den som används av tillverkaren. PMEM-nycklar lagras i parameterminne och BIOS-nycklar lagras i BIOS, såsom visas i FIG 9. Denna mekanism skulle också kunna användas till att tillåta redundans i det fallet den BPK som hyses iden offlinesatta Bastion-servem på något sätt förloras.

REDUNDANTA STARTPRODUKTIONSNYCKLAR 10 15 20 25 30 Lift lf* .rä f' ”r 5:5 v! 24 Bastionsserverii är designad att vara ett mycket säkert sätt att lagra den hemliga nyckeln som motsvarar den som finns i BIOS. Trots detta är det ofta klokt att tillhandahålla en reserv till dessa nycklar och detta innebär att det kan finnas risk att de exponeras utanför Bastionvärddatom. Eftersom nycklarna typiskt kontrolleras i följd på målenheten kan denna mekanism användas till att anordna en andra Bastion som också kan signera start- och installationsavbildningar. I fallet där Bastionen inte fungerar, kan en ny Bastion initieras och nya nycklar distribueras till alla relaterade målenheter med användning av den andra produktions-Bastionen. En annan metod kan vara att förbereda en ny bastion hos Applikationspartnem och signera en installationsavbildning innehållande den nya nyckeln med den existerande Bastionens hemliga nyckel.

FIG. 10 illustrerar den säkra startladdaren som finns i BIOS-flash-minnet såsom det är implementerat i den visade utföringsforrnen av uppfinningen. Den första modulen är självtest vid strömtillslag. Vid lyckat strömtillslag laddar systemet en drivrutin för filsystemet som används på startmediet, exempelvis ett ñlbaserat system såsom VFAT, men även andra filbaserade system kan användas. Såsom tidigare har nämnts har detta tillvägagångssätt den önskvärda fördelen att eliminera behovet av att använda förforrnatterade medier för en huvudstartpost (Master Boot Record) och därigenom tillåta att en hel rad av konsumentminnesprodukter kan användas såsom mobila telefoner, MP3-spelare, etc. Alla dessa vanliga konsumentartiklar kan användas till att tjäna som startenhet utan att sätta säkerheten i fara, eftersom digitala signerade avbildningar måste verifieras innan de tillåts att laddas in. Slutligen väljer systemet ett sekundärt eller primärt startmedium och hämtar startfiler med associerade signaturfiler.

Signaturerna kontrolleras mot nycklar som är lagrade i parameterminne (utanför BIOS) eller mot en nyckel lagrad i själva BIOS.

LAYOUT FÖR STARTMEDIUM FIG. ll visar en exemplifierande layout för startmedierna. Lösningen blir mer robust när medierna är uppdelade i partitioner och startpartitionen behålls som ROM (read- only memory). Compact flash-minnen är vanliga i industriella datorer, men en känd nackdel är begränsningen av läscykler som de kan hantera innan data blir otilltörlitlig. 10 15 20 25 30 I ylg! :ß mi] ägg; :klä 25 Operativsystemavbildningen placeras i en enda stor fil som autenticeras av utvecklaren med den digitala signaturen som har genomgått en lyckad verifiering under inladdningen till det intema RAM (random access memory). Operativsystemet som är lokaliserat på startpartitionen är ansvarigt for att säkerställa att rotpartitionen (productionsfilsystemet) är korrekt. Denna procedur är inte en del av den säkra starten men det finns ”krok” (”hook”) i systemet tör utförande av detta test. Det skall noteras s att det inte firms något krav for att ha mer än ett filsystem på USB-stickan eftersom det exempelvis for fristående distribution (offline deploynnent) också kan vara en enda VFAT-partition som bär installationsavbildningen.

PARAMETRAR LAGRADE PÅ MODERKORTET FIG. 12 visar en exemplifierande konfigurering av det icke-flyktiga parameterminnet i enlighet med den visade utfóringsformen av föreliggande uppfinning. Parameterminnet måste vara tillgängligt både för BIOS och för operativsystemet. Serienumret skrivs typiskt under produktionen av enheten och kan användas i applikationsceitifikatet när systemet distribueras. De kryptografiska nycklarna kan ersättas under installationsproceduren och ”ATB”-parametem kan sättas till att tvinga fram en andra installation (återställriing/uppgradering) av systemet. Parameterminnet håller systemets tillstånd oberoende av sekundära medier (USB-sticka/Compact Flash).

”Diitf-parametern är ett heltal som inkrementeras varje gång systemet försöker starta från det primära mediet. Den sätts till noll om systemet gör en lyckad avstängning.

”Max””-parametem begränsar antalet staitforsök på det sättet att när ”diItW-parametern når värdet hos ”max”-parametern utförs någon användardeflnierad åtgärd, exempelvis att kontakta servrar i ett bakgrundssystem eller att sända ett larm etc. En liknande uppsättning parametrar håller reda på det sekundära mediet, dvs. ”usb_dirty”, ”usb_max” etc. av samma skäl.

Utfóringsfornien använder en AT97SC3202 TPM minnesmodul från Atmel (men andra typer av minnen kan användas), vilket har visat sig filngera väl med uppfinningen, och l0 15 20 25 30 26 erbjuder en mekanism med hög ”manipuleringssäkerhet” för lagring av nycklar på systemet. Nycklarna genereras inuti chipet under initiering och bara den öppna nyckeln extraheras. En tillverkare kan instrueras att sända en signerad lista av alla öppna nycklar till servrar i ett bakgrundssystem för att försäkra att inga repliker av systemet kan introduceras under installation, genom att de kontrolleras innan nedladdning av OS- avbildningarna tillåts.

START FRÅN SEKUNDÅRA MEDIER FIG. 13 är ett flödesschema som illustrerar startproceduren för operativsystemet när det är på ett sekundärt medium (USB-sticka) i enlighet med utföringsformen. BIOS- startladdaren sätter bevakningsmekanismen till att återställa systemet etter 300 sekunder och startar en applikation för att undvika återställning av bevakningsmekanismen. Den kontrollerar sedan om tillståndet hos ”ATB”-para1netern är satt till noll, om den är det startar installationen av programvara till det primära mediet. Efter installationen ändrar den värdet hos ”ATB”-parametem till ett och försöker starta om. Om ”ATB”- parametem redan är satt till l, och ”Dirty”-parametern har ett värde mindre än ”max”, inkrementerar den ”Dirtyïparametem och exekverar ett kodhopp till den primära rotpartitionen. Detta är möjligt eftersom koden redan har laddats in i RAM. Om ”Di1ty”-flaggan överskrider ”max”, vidtar den lämpliga åtgärder såsom att kontakta och varsko servern i bakgrundssystemet.

START FRÅN PRIMÄRA MEDIER Processen för produktionssystemet är något enklare än processen för installationen och återställningsmedier, såsom visas i FIG. 14. Införandet av bevakningsmekanismen i BIOS hanteras i produktionssystemet. Startskriptet kan användas till att återinstallera USB-stickan medan systemet är utformat att överleva även om strömmen förloras under en uppgradering av det sekundära mediet. Innan USB-stickan kan uppgraderas via tjärranslutning skall startskript biblioteket laddas med ett skript som läser parametem ”Dirty_USB”, vilket upptäcker om det var något problem under en tidigare uppgradering, och återinstallerar OS-avbildningen. 10 15 20 25 30 wmi »MJ ...aa lill u: l mi' 27 MÅLENHETENS IDENTITET För att detektera om en obehörig (icke auktoriserad) målenhetsklon försöker installera programvaruavbildningen, är det önskvärt att vara kapabel att identifiera vilka enheter som tidigare på ett legitimt sätt har utfört en sanktionerad nedladdning. Försök av oidentifierade eller klonade enheter att installera redan tidigare installerade avbildningar kommer att hindras. identiteten hos varje målenhet kan fastställas delvis genom användning av ett tillverkarallokerat unikt serienummer hos varje enhet. Detta tillsammans med domännamnet kan användas till att unikt identifiera målenheten ifi-âga.

Till exempel kommer en enhet som har serienummer 1234 och som arbetar från domänen nano-system.com att vara detekterbar som l234@nano-system.com.

Provisoneringssystemet genererar ett certifikat med användning av den hoplänkade strängen som särskiljande etikett i det digitala certifikatet. Oavsett om målenheten distribueras i en offline-miljö eller en online-miljö, sänder provisionerinsgsystemet målenhetens certifikat, varefter systemet kan delegeras till Applikationsägaren. Det skall noteras att certifikatet kan genereras på olika sätt beroende på miljön.

ONLINE-MILJÖ Om målenheten saknar ett RSA-chip i en startar den installationsavbildningen och etablerar en krypterad och ömsesidigt autenticerad SSL- online-miljö anslutning. Den extraherar målets serienummer och sänder en certifikatbegäran till installationsservern. lnstallationsservern kontrollerar om det faktiska målet har ett certifikat och, om så inte är fallet skickas begäran till CA-servem som returnerar ett certifikat som lagras på servern och sedan laddas ner till målenheten. Serienumret hos en legitim målenhet skulle existera i provisioneringsdatabasen och målenhetens tillstånd mäste levereras.

Om målenheten innehåller ett RSA-chip i online-miljön, kan den hemliga nyckeln inte extraheras från hårdvaran efiersom chip anses vara praktiskt taget manipuleringssäkert.

Nycklarna genereras inuti chipet som svar på en begäran om nyckelgenerering, vilket lO 15 20 25 30 28 äger rum på fabriken eller hos en betrodd Logistikpartner. Fabriken (eller Logistikpartnem) signerar en lista över alla utfärdade målenheter och sänder listan till Provisioneringspartnern. Målenheten kör den initiala installationsavbildnirigen och tillhandahåller den öppna nyckeln genom SSL-anslutningen där den kontrolleras mot databasen. Om nyckehi existerar i databasen försäkras provisioneringssystemet om att den korrekta enheten är ansluten och kommer att acceptera certifikatsbegåran och, med assistans av CA-servern, retumera ett certiflkat i X509-forrnat med serienummer och domännamn.

OFFLlNE-ENVIRONMENT I fallet när målenheten saknar ett RSA-chip i en oflline-miljö kommer installationsavbildningen att innehålla den kod som är nödvändig för att generera X5 09- nycklar när systemet startar forsta gången. Avbildningen har en öppen nyckel som resulterande tillsammans med serienumret. krypterar de nycklama Installationsavbildningen är pro grammerad att skriva tillbaka den krypterade datan på USB-stickan och att notifiera operatören via exempelvis en displayenhet. I detta fall returnerar operatören den krypterade datan till Provisioneringspartnem som dekrypterar filerna och lagrar datan.

Om innehåller ett tillåter målenheten RSA-chip i installationsavbildningen RSA-chipet att generera X509-nycklarna när systemet startar oflline-miljön, fór forsta gången. Avbildningen innehåller en öppen nyckel som krypterar de resulterande nycklarna tillsammans med serienumret. Installationsavbildningen är programmerad att skriva tillbaka den krypterade datan till USB-stickan och att meddela operatören via displayen.

Operatören retumerar den krypterade datan till Provisioneringspartnern som dekrypterar filerna och lagrar deras data.

SEKVENSDIAGRAM FÖR ONLINE-INSTALLATION FIG. 15 illustrerar ett exemplifierande sekvensdiagram för scenariot för online- installation i enlighet med uttöringsformen. De följande stegen kan ses från 10 15 20 25 30 53? B92 29 meddelandena som visas i sekvensdiagrammet. När målenheten startar får den en dynamisk IP-adress och utför ett DNS-uppslag efter en SRV-post och får en lista över giltiga installationsservrar. Innan SSL-anslutningen etableras måste klockan synkroniseras, annars skulle certifikatet kunna förkastas. Klienten presenterar certifikatet (IK) som är sammanpackat med installationsavbildningen tillsammans med det iörsäljarunika serienumret, lnstallationsservern utför ett uppslag mot logistikdatabasen, och om målet är i korrekt systemtillstånd uppdateras tillståndet och det returneras ett kvitto som kommer att användas i efterkommande begäranden. Om målenheten inte har ett RSA-chip hoplänkas serienumret och domännamnet och används i ett certifikat. Det slutliga steget relaterar till målet som utför en anslutningskontroll (connectivity check) mot serviceklustret innan den kopplar bort sig från installationsklustret.

FIG. 16 visar ett exemplifierande tillståndsdiagram över Logistikservem. I fabriken måste parameterminnet som finns på moderkortet laddas med initialtillstånd och ett unikt serienummer. Enheten kan fraktas från fabriken direkt till slutanvändare eller via en Logistikpartner. Systemet tilldelas till en specifik slutanvändare och Logistikservern ändrar tillståndet till LEVERERAD. Detta är det enda tillståndet i vilket systemet kommer att acceptera en programvarunedladdning för att förhindra icke-auktoriserad kloning av enheter från en tillverkare. Slutanvändaren sätter in det sekundära startmediet (USB-stickan) vilket kontaktar installationsservem där INSTALLATIONS- tillstånd kan resultera i antingen misslyckande eller fi-amgång, i det senare fallet kommer enheten att återstarta och använda det primära mediet. Logistikservem ändrar tillståndet till AKTIV när produktionsapplikationen meddelar att enheten är fiamgångsrikt installerad. UTGÅNGS-tillståndet används till att iiidikera att en fullständig programvaruåterställniiig krävs eller att det krävs fullständigt utbyte av enheten, i vilket fall servicepersonal varskos och sänds till området.

Den föregående beskrivningen av de föredragna utíöringsforrnerna av uppfmningen har presenterats som illustration och beskrivning. Den är inte avsedd att vara uttömmande eller att begränsa uppfinningen till exakt de former som visas, eftersom många modifikationer eller varianter av den är möjliga i ljuset av de ovanstående mfl i u LE! iß Pat: 30 beskrivningarna. Följaktligen skall det förstås att sådana modifikationer och varianter förmodas falla inom uppfiriningens omfång. Utfóringsfonnen valdes fór att förklara uppfinningens principer och dess praktiska tillämpning, och därmed möjliggöra fór fackmannen att utnyttja uppfinningen for den särskilt avsedda användningen. Det är därför avsikten att de efterföljande patentkraven inte skall ges en restriktiv tolkning men skall ses såsom omfattande varianter och modifikationer som är avledda från det visade uppfinningsenliga sakinnehållet.

Claims (20)

10 15 20 25 30 3l Patentkrav

1. l. En metod att provisionera programvara for initiering och hantering av datorsystem på ett säkert sätt, varvid nämnda datorsystem vart och ett inkluderar ett primärt medium i form av ett internt primärminne, ett icke-flyktigt minne för lagring av system-BIOS- kod och ett icke-flyktigt parameterminne fór lagring av systemrelaterad information. samt BIOS-funktioner fór implementering av en bevakningsmekanism för säkerställande av att systemet är i ett känt tillstånd, av digital signaturverifiering och av filbaserad access i filsystem, varvid nämnda metod innafattar stegen att: detektera närvaron av ett borttagbart sekundärt medium kopplat till nämnda datorsystem, varvid det på nämnda sekundära medium är inkluderat en operativsystemavbildning och relaterade startfiler, som var och en är digitalt signerade, och om det borttagbara sekundära mediet inte är närvarande försöker systemet starta från det intema primära mediet; kontrollera om antalet tidigare staittörsök från det sekundära mediet har överskridit ett fórbestämt maximalt antal, och om så är fallet försöker systemet starta från det primära mediet, annars inkrementerar systemet parametern för antalet starttörsök från det sekundära mediet; aktivera en bevakningsmekanism inom BIOS för att säkerställa att systemet är i ett känt tillstånd; bereda åtkomst till filerna på det borttagbara sekundära mediet och verifiera de digitala signaturema fór filema hos det sekundära mediet, om de digitala signaturema fór filerna hos det sekundära mediet inte verifieras styrs systemet att starta om, om de digitala signaturema för filerna hos det sekundära mediet verifieras startar systemet från det borttagbara sekundära mediet, och om operativsystemavbildningen hos det sekundära mediet verifieras laddas det in i systemet och om den primära operativsystemavbildningen är giltig exekveras ett kodhopp till operativsystemavbildningen i det primära mediet så att övergången är transparent och exekvering kan fortsätta där den lämnades. 10 15 20 25 30 *'25 -fš ..___.t “J 5 933 32

2. Metoden enligt krav l, varvid steget att försöka starta 'från det primära mediet innefattar stegen att: detektera om det primära mediet är närvarande, om så är fallet kontrollera om antalet tidigare startfórsök (Dirty_CF) från det primära mediet har överskridit ett fórbestämt maximalt antal (CF_max), om så är fallet kontrollerar systemet om antalet starttörsök från det sekundära mediet (Dirty_USB) har överskridit dess maximum (USB-max) och, om så är fallet återställs startfórsökparainetrarna för det sekundära mediet och det primära mediet till noll (Dirty_USB=0 och Di1ty_USB=0) och systemet startas om; om antalet start försök fiån det primära mediet (Dirty_CF) är mindre än det förbestämda maximala antalet (CF__max) inkrementerar systemet parametem för antalet primära startfórsök (Dirty_CF) och aktiverar bevakningsmekanismen; och bereda tillgång till operativsystemavbildningen och startfilerna från det primära mediet och verifiera de digitala signaturema om de digitala signaturema inte verifieras omstartas systemet, om de digitala signaturerna verifieras startar systemet från det interna primära mediet.

3. Metoden enligt krav l och 2, varvid det vid initiering av systemet exekveras ett BIOS som är anordnat att innefatta: kod for fórinställd (by default) initial läsning från det boittagbara sekundära mediet; kod för att ge ett filsystem förmåga till filbaserad åtkomst av filer; kod för verifiering av de digitalt signerade filerna på det sekundära mediet med användning av den motsvarande öppna nyckeln; och kod för implementering av en bevakningsmekanism för detektering av systemtillståndet och lagring i ett icke-flyktigt parameterminne på systemets moderkort.

4. Metoden enligt något av föregående krav, varvid bevakningsmekanismcn säkerställer att systemet är i ett känt tillstånd, om så inte är fallet omstartas systemet.

5. Metoden enligt krav 4, varvid, om antalet startförsök 'från det primära mediet (Dirty_CF) och det sekundära mediet (Dirty_USB) har överskridit sina maximalvärden 10 15 20 25 30 EH m3! u: u: re 33 (CF__max och USB_max), återställs startförsökparametrarna för det sekundära mediet och det primära mediet till noll (Diity_USB = 0 and Dirty_USB = 0) och systemet omstartas varvid systemet fortsätter en cykel av omstarter till en giltig operativsystemavbildning påträffas fiån ett på nytt infört sekundärt medium.

6. Metoden enligt något av föregående krav, varvid filerna är lagrade på portabelt sekundärt medium såsom ett USB-kompatibelt lagringsmedium såsom en MP3-spelare, ett USB-flashminnessticka/enhet, eller en USB-minidiskenhet eller liknande portabel enhet.

7. Metoden enligt något av föregående krav, varvid de digitala signaturema verifieras med användning av asymmetrisk kryptering.

8. Metoden enligt något av föregående krav, varvid en öppen asymmetrisk nyckel oberoende lagras och hämtas från ett icke-flyktigt parameterininne placerat på moderkortet såsom ett flashminne eller ett EEPROM.

9. Metoden enligt något av föregående krav, varvid operativsystemavbildningen (OS-avbildningen) uppdateras över en trådbunden eller trådlös anslutning via ISDN eller en mobilnätstandard såsom GSM, WCDMA, CDMA2000, eller WiMAX.

10. Metoden enligt något av föregående krav, varvid operativsystemavbildningen (OS-avbildningen) år en avbildning av ett Linux-operativsystem varvid kodhoppet till en passande kärna inträffar när ”ATB” är satt till ett.

11. l 1. Metoden enligt något av föregående krav, varvid metoden provísionerar mjukvaran via kluster som inkluderar ett Servicekluster, Installationskluster och ett Logistik-kluster som har gränssnitt med måldatorsystemen.

12. Ett system för provisionering av programvara fór initiering och hantering av datorsystem på ett säkert sätt, varvid nämnda datorsystem vart och ett inkluderar ett primärt medium i form av ett internt primärminne, ett icke-flyktigt minne för lagring av 10 15 20 25 30 i "' I int? Ilzfil 34 system-BIOS-kod och ett icke-flyktigt parametermiiine, samt BIOS-fiinktioner för implementering av en bevakningsmekanism för säkerstållande av att systemet är i ett känt tillstånd, av digital signaturverifiering och av filbaserad access i filsystem, varvid nämnda datorsystem i nämnda provisioneringssystem innefattar: nämnda icke-flyktiga parameterminne åtkomligt för datorenheten för oberoende lagring av information relaterad till systemets tillstånd och kryptografiska nycklar för verifiering av filer; organ för detektering av närvaron av ett borttagbart sekundärt medium kopplat till nämnda datorsystem, varvid det på nämnda sekundära medium är inkluderat en operativsystemavbildning och relaterade startfiler, som var och en är digitalt signerade, och det är anordnat så att om det borttagbara sekundära mediet inte är närvarande försöker systemet starta från det primära mediet; organ för att kontrollera om antalet tidigare startförsök från det sekundära mediet har överskridit ett förbestämt maximalt antal, och det är anordnat så att om så är fallet försöker systemet starta från det primära mediet, annars inkrementerar systemet parametern för antalet startförsök från det sekundära mediet; organ för att aktivera en bevakningsmekanism inom BIOS för att säkerställa att systemet är i ett känt tillstånd; organ för att bereda åtkomst till filerna på det borttagbara sekundära mediet och verifiera de digitala signaturema för filerna hos det sekundära mediet, varvid det är anordnat så att om de digitala signaturema för filema hos det sekundära mediet inte verifieras styrs systemet att starta om, om de digitala signaturema för filerna hos det sekundära mediet verifieras startar systemet från det borttagbara sekundära mediet, och om operativsystemavbildningen hos det sekundära mediet verifieras laddas det in i systemet och om den primära operativsystemavbildningen är giltig exekveras ett kodhopp till operativsystemavbildningen i det primära mediet så att övergången är transparent och exekvering kan fortsätta där den lämnades.

13. Ett system enligt krav 12, varvid organ för att försöka starta från det primära mediet vidare innefattar: organ för att detektera om det primära mediet är närvarande, om så är fallet 10 15 20 25 30 35 organ for att kontrollera om antalet tidigare startiörsök (Dirty_CF) fiån det primära mediet har överskridit ett fórbestämt maximalt antal (CF_max), om så är fallet kontrollerar systemet om antalet starttörsök från det sekundära mediet (Dirty_USB) har överskridit dess maximum (USB-max) och, om så är fallet återställs startfórsökparametrarna för det sekundära mediet och det primära mediet till noll (Di1ty_USB=0 och Dirty_USB=0) och systemet startas om; for fallet att antalet startfórsök från det primära mediet (Dirty_CF) är mindre än det törbestämda maximala antalet (CF_max) inkluderar systemet organ för att inkrementera parametern för antalet primära startfórsök (Dirty_CF) och organ for att aktivera bevakningsmekanismen; och organ för att bereda tillgång till operativsystemavbildnirigen och startfilerna *från det primära mediet och verifiera de digitala signaturema, om de digitala signaturema inte verifieras omstartas systemet, om de digitala signaturema verifieras startar systemet från det intema primära mediet.

14. l4. Ett system enligt krav 12, varvid datorsystemet inkluderar ett bios som är anordnat att innefatta: kodorgan for törinställd initial läsning från det borttagbara sekundära mediet; kodorgan for att ge ett filsystem fórrnåga till filbaserad åtkomst av filer; kodorgan for verifiering av de digitalt signerade filerna på det sekundära mediet med användning av den motsvarande öppna nyckeln; och kodorgan för implementering av en bevakningsmekanism fór detektering av systemtillståndet och lagring i ett icke-flyktigt parameterminne på systemets moderkort.

15. Ett system enligt krav 12, varvid, bevakningsmekanismen säkerställer att systemet är i ett känt tillstånd, om så inte är fallet omstartas systemet till ett känt tillstånd.

16. Ett system enligt krav 12, varvid det portabla sekundära mediet är ett USB- kompatibelt portabelt lagringsmedium såsom en MP3-spelare, ett USB- flashmirmessticka/ enhet, eller en USB-minidiskenhet eller liknande portabel enhet. 10 15 36

17. Ett system enligt krav 12, varvid organen lör verifiering av de digitala signaturema använder asymmetrisk kryptering.

18. Ett system enligt krav 12, varvid det icke-flyktiga parameterminnet är placerat på moderkortet såsom ett flashminne eller ett EEPROM.

19. Ett system enligt krav 12, varvid provisioneringssystemet för mjukvara uppdaterar datorsystemen via en trådbunden anslutning, en trådlös anslutning eller i en fristående konfiguration.

20. Ett system enligt kraven 12 - 19, varvid provisioneringssystemet är anslutet till ett flertal kluster som inkluderar ett Servicekluster, ett Installationskluster, och ett Lo gistikkluster for gränssnittsanslutning till datorsystemen.