Inloggning

Inloggning med ett smartkort börjar när en användare sätter i ett kort i en läsa- re som signalerar till operativsystemet att fråga efter en PIN-kod istället för an- vändarnamn, domännamn och lösenord. Att sätta i kortet motsvarar sekvensen Control-Alt-Delete (eng. secure attention sequence) som används vid inloggning med lösenord för att för att säkerställa att lösenordet verkligen hanteras av Win- dows GINA och inte ett avlyssningsprogram. Användarens PIN-kod används en- dast för autentisering mot kortet och inte mot domänen, ett certifikat lagrat på kortet används istället för domänautentiseringen genom Kerberos med PKINIT- utökningen. [12]

När användaren angivit sin PIN-kod börjar operativsystemet utföra en rad operationer för att avgöra om användaren kan identifieras och autentiseras ba- serat på informationen som tillhandahållits (PIN-koden och kortet). Först verifie- ras att certifikatet på kortet är giltigt och är av en typ som är avsett för inlogg- ning i Windows. När det är utfört används CAPI (se avsnitt 2.3.2) för att verifiera den digitala signatur som skickats av användaren vid inloggningen. Verifikatio- nen använder den publika nyckeln från användarens certifikat för att bevisa att inloggningsbegäran kommer från innehavaren av den publika nyckeln. Eftersom certifikatet hämtades från kortet och signaturen gjorts med den privata nyckeln som endast finns på samma kort, måste signaturen vara giltig eftersom använda- ren var tvungen att autentisera sig mot kortet för att kunna skapa den digitala signaturen. [12]

När en användare är bortkopplad från nätverket eller domänkontrollanten är onåbar på grund av nätverksfel, måste användaren ändå kunna logga in på sin arbetsstation för att utföra sina arbetsuppgifter. Med lösenord stöds detta genom att användarens lösenord från tidigare inloggningar lagras i hashad form och jäm- förs med hashvärdet av lösenordet som användaren anger vid Windows GINA. Om hashvärdena är identiska kan användaren autentiseras på den lokala datorn. I fallet då användaren loggar in med ett smartkort, krävs att extra information, som tidigare krypterats med användarens publika nyckel, dekrypteras. [12]

Kapitel 3

Metod

I det här kapitlet beskrivs metoden som använts för att uppnå projektmålen och ger en överblick över de moment som jag valt att dela upp projektet i. De centrala momenten beskrivs därefter mer ingående.

3.1

Arbetsgång

I det här avsnittet ges en översikt över de aktiviteter utförts. Dessa redovisas i kro- nologisk ordning tillsammans med en kort beskrivning av vad respektive moment består av.

1. Planering

Jag förberedde mig genom litteraturstudier och diskussioner med uppdrags- givaren för att definiera uppgiften. Jag valde metod för projektet och en grov planering gjordes upp. En mer detaljerad planering har sedan gjorts inför varje fas av projektet.

2. Behovsanalys

Grunden för projektet är behoven som företaget har. För att identifiera des- sa behov har jag genomfört ett antal intervjuer med användare av systemen samt teknisk personal, se avsnitt 3.2. Jag har även läst företagets policy som berör säkerhet och studerat de system som finns idag. Resultaten har jag se- dan sammanställt i en lista över önskvärda egenskaper hos systemet. Dess- utom har jag installerat och prövat några av de autentiseringsprodukter som finns tillgängliga på företaget, för att på så vis förstå problematiken bättre. 3. Omvärldsanalys

Genom att kontakta leverantörer, hämta information på Internet och besö- ka Infosecurity-mässan skapade jag mig en bild av de produkter som finns tillgängliga på marknaden och inhämtade information om dem.

4. Produktanalys

Jag gjorde en grov uppdelning av de produkter som jag fann intressanta att undersöka och kunde då avföra några produktkategorier som olämpliga. De produkter som fanns kvar efter det urvalet jämförde jag närmare med egenskaperna som togs fram under behovsanalysen. Se avsnitt 3.3 för att vidare se hur urvalet gick till.

5. Testinstallationer

De produkter som var mest intressanta efter produktanalysen installerades i ett testnätverk för att undersöka om de fungerar lika bra i praktiken som de teoretiska specifikationerna utlovade. Dessutom var detta ett bra sätt att få underlag för rekommendationer för hur företaget kan gå vidare med en sådan lösning. Se avsnitt 3.4, där testarbetet beskrivs.

6. Utvärdering

Avslutningsvis sammanställdes de lärdomar jag dragit under projektet och resultaten dokumenterades.

3.2

Intervjuer

Under arbetet med att identifiera företagets behov har jag genomfört fem intervju- er med anställda på företaget för att på så sätt få en bild av vilka behov de olika användarna har. Målet var att få veta vilka problem personalen ser med dagens system, vilka specifika behov de har i sin nätverksmiljö samt vad de förväntar sig av ett framtida system. Jag valde att utföra intervjuerna i en fri form där de intervjuade till största delen fick berätta fritt som svar på de frågor jag ställde. Dock såg jag till att styra diskussionen tillräckligt för att få svar på de frågor jag förberett och som jag anpassat efter vad jag ansåg var respektive persons expert- område. Denna intervjuform passade bra för detta projekt då informationen jag ville få fram var åsiktsbetonad art och inte direkt mätbar, i annat fall kunde en enkätundersökning och ett större antal personer kommit i fråga.

De intervjuade valdes dels ut för att de använder nätverksresurser frekvent och dels som representanter för olika avdelningar som antogs kunna ha speciella önskemål och arbetssätt som kräver särskild hänsyn. Till exempel representerar en av de intervjuade testavdelningen som har behov av att arbeta på många dato- rer samtidigt och en annan har stor erfarenhet av fjärrinloggning. Jag valde även att intervjua personal med ansvar för drift och administration av IT-systemen på företaget samt personal med ansvar för nätverkssäkerheten. Syftet med att inter- vjua dessa personer var att utröna vilka krav som ställs på produkterna ur ett säkerhetsperspektiv. Intervjuerna med personalen lade grunden för de krav på användarvänlighet, säkerhet och kompatibilitet som jag ställt upp under behov- sanalysen. Viss information som inte direkt kunnat översättas till krav på systemet har även sammanställts för att komplettera kraven. Sammanställningen av inter- vjuerna presenteras i kapitel 4.

3.3 Produktanalys 15

3.3

Produktanalys

När företagets behov var identifierade och sammanställda blev nästa steg att ge- nomsöka marknaden efter produkter som ansågs kunna uppfylla behoven och kraven. En stor källa var Internet, genom produktrecensioner och distributörers hemsidor. Dessutom fick jag möjlighet att besöka mässan Infosecurity i Stockholm september 2003, där jag träffade representanter för flera av de för mig aktuella le- verantörerna. Diskussionerna på mässan gav mig nya infallsvinklar och gjorde mig uppmärksam på produkter och företag som jag inte övervägt innan.

Listan över produkterna som jag tagit fram kan inte anses vara helt uttöm- mande, då det finns så många företag som marknadsför säkerhetslösningar och så många modeller av produkter att det inte är rimligt att få med alla. Jag har in- riktat mig på att få med produkter som använder olika teknologier för att uppfylla kraven och valt att dela in dessa i beskrivande kategorier efter lösningens art. An- ledningen till uppdelningen i produktkategorier var att underlätta ett grovt urval av produkterna. Istället för att jämföra varje enskild produkt med behoven kunde jag på ett tidigt stadium, genom att gruppera produkterna efter deras egenskaper, sålla bort ett flertal lösningar som inte uppfyllde vissa av de högt prioriterade kra- ven. Jag har försökt att få med produkter från olika leverantörer i varje kategori för att inte missa någon produkts speciella funktioner.

Efter en första grov utrensning gjorde jag en mer noggrann undersökning av kvarvarande produkter med utgångspunkt i behoven. Hur väl en produkts egen- skaper uppfyllde kraven har bedömts ganska subjektivt, eftersom de flesta egen- skaper hos en säkerhetsprodukt är svåra att kvantifiera. Detta bör läsaren ha i åtanke under läsningen av urvalet i kapitel 5. För att på ett mer strukturerat sätt kunna jämföra olika produkter och produktkategorier har jag utgått från det ram- verk för jämförelse av autentiseringsprodukter som föreslås i The Authentication Scorecard [22], dock med viss anpassning för att passa mitt projekt bättre. Bland annat utelämnade jag de föreslagna punkterna som gäller kostnader, då projekt- uppgiften bestod av att finna den tekniskt och funktionellt mest lämpliga pro- dukten och inte nödvändigtvis den som har lägst pris. I tabell 3.1 finns de punkter som jag valt att behålla och använt som stöd för utvärderingen. Det visade sig att många av de krav som ställdes upp efter intervjuerna överlappade dessa punkter, vilket minskade nyttan med punkterna något. De gjorde dock ändå nytta som en grund för jämförelse utanför de direkta behoven.

Som en del i ramverket föreslås även ett mer kvantitativt angreppssätt som ba- seras på att egenskaper hos produkterna tilldelas siffervärden och att produkter jämförs genom att dessa värden viktas och kombineras. Eftersom denna tilldel- ning av värden till största delen kommer att vara subjektiv ser jag inte att denna metod skulle tillföra något större värde för mitt projekt och har därför valt att inte använda den metoden.

Tabell 3.1.Stödpunkter för produkturval

Lämplighet för användare

Användarvänlighet Hur lätt är det för användare att lära sig att använda produkten? Hur bekvämt är det att använda produkten ofta?

Flyttbarhet Hur mobil är lösningen, d v s krävs speciell programvara och hårdvara?

Ytterligare använd- ningsområden

Kan produkten användas för mer än att få tillgång till nätverket (t ex inpassering, foto-ID, signa- turer)?

Lämplighet för företaget

Relativ säkerhet Är autentiseringen stark nog och implementationen säker nog? Kompatibilitet Fungerar produkten med system

som finns idag?

Skalning Kan lösningen skalas upp till den nivå som behövs idag? I framti- den?

Framtida möjligheter Vilka framtida möjligheter ger produkten? Vilka skulle vara in- tressanta?

Källa: [22] med bearbetning av författaren

3.4

Testarbete

Efter att de för projektet mest intressanta produkterna valts ut inskaffades ett ex- emplar av respektive produkt för utvärdering. Detta avsnitt ger en beskrivning av hur testarbetet bedrevs och vilken testmiljö som användes. För att inte tynga tex- ten med detaljer om konfigurationen har dessa utelämnats och återfinns istället i bilagorna A, B samt C. Jag har även valt denna uppdelning för att göra det även lättare att använda informationen som separata installationsanvisningar.

3.4.1

Testmiljö

Ett enkelt nätverk sattes upp för att kunna testa produkterna under så realistiska förhållanden som möjligt utan att riskera att störa företagets övriga nätverkstrafik. Testmiljön bestod av en serverdator och två klientdatorer samt en enkel switch för att koppla samman dessa. Microsoft Windows Server 2003 valdes som operativsy- stem för servern eftersom det kommer att finnas på företagets servrar hädanefter. Servern installerades primärt för att vara domänkontrollant med Active Directory i testnätverket. Dessutom konfigurerades den som CA för att utfärda och hantera testcertifikat. Se vidare bilaga A för en beskrivning av hur servern konfigurerades.

3.4 Testarbete 17

Klientdatorernas operativsystem var Microsoft Windows 2000 Professional SP4 eftersom det finns på företagets arbetsstationer idag. Klienterna installerades ut- an några särskilda inställningar och utöver operativsystemet installerades även Microsofts Officepaket. För anpassningar till testerna av produkterna, se bilagor- na B respektive C.

Datorerna som användes har motsvarande prestanda som äldre arbetsstatio- ner, vilket kan ha påverkat hastigheten hos produkterna negativt. Jag har därför inte kommenterat prestandan hos produkterna ingående där det inte varit märk- bar skillnad mellan dem. Jag anser att det är realistiskt att anta att användningen upplevs som mycket snabbare när det sker med en mer kraftfull server och mo- dernare arbetsstationer. Alla datorerna var utrustade med Pentium III-processor och serverns klockfrekvens var 730 MHz till skillnad från klientdatorernas nå- got blygsammare 550 MHz. Servern och den ena klientdatorn var utrustad med 256 megabyte arbetsminne och den andra klientdatorn hade endast 128 megabyte minne.

Eftersom testerna av produkten RSA Passage fortskred väl och produkten upp- fyllde kraven, testade jag den även på två arbetstationer i företagets nätverk för att fastställa att det inte medförde oväntade problem. Se vidare kapitel 6 för infor- mation om detta.

3.4.2

Genomförande av tester

Efter studie av dokumentationen som medföljde respektive produkt gjordes en plan för vilka alternativ som skulle väljas under installationen samt vilka anpass- ningar som behövde genomföras på klientdatorerna och servern. Installationerna anpassades för att på bästa möjliga sätt medge produkterna att uppfylla de krav som ställts på dem. När en produkt var installerad och konfigurerad använde jag mig av den under en längre tidsperiod i testnätverket för att bekanta mig med den samt kunna upptäcka eventuella brister som kanske inte skulle märkas vid en kor- tare användning. Dessutom prövade jag att använda produkten för att genomföra de uppgifter som den enligt kraven ska klara av.

Efter att ha utvärderat hur väl en produkt uppfyllde grundkraven inriktades testerna mot den funktionalitet som produkten har utöver grundkraven. Kom- pletterande konfigurering och anpassning av produkten och servern gjordes i de fall det behövdes. Utvärderingen av en produkt ansågs avslutad när alla krav ge- nomarbetats och det inte fanns mer extrafunktionalitet att pröva.

Efter att en produkt testats klart togs alla tillhörande komponenter som in- stallerats på både server och klientdatorer bort (både medföljande mjukvara och eventuella drivrutiner) och alla anpassningar av operativsystemen nollställdes in- nan nästa produkt testades. Detta gjordes av två anledningar, dels för att mins- ka risken för att problem skulle kunna uppstå genom krockar mellan operativ- systemskomponenter och drivrutiner, dels för att inte missa någon komponent som kanske behövde installeras separat men redan installerats för en tidigare pro- dukt.

Kapitel 4

Behov

I det här kapitlet redovisas de resultat som kommer från projektets behovsana- lysfas. Önskade egenskaper på det efterfrågade systemet och övrig information presenteras i det här kapitlet. På grund av denna presentations omfattning förkla- ras först detta kapitels upplägg i avsnitt 4.1 för att underlätta för läsaren.

4.1

Upplägg

I tabell 4.1 återfinns en kort sammanställning av de krav och önskemål på inlogg- ningssystemet som kommit fram under intervjuer med användare och personal med ansvar för nätverk och säkerhet. Jag har valt att tilldela varje egenskap en kategori och en prioritet för att underlätta arbetet med att, utifrån dessa, välja produkter. De benämningar jag använt är endast korta beskrivande namn för att särskilja egenskaperna, en utförlig beskrivning av varje krav finns i avsnitt 4.2 till- sammans med motiveringar till valda prioriteter. Slutligen redovisas komplette- rande information och önskemål som inte direkt hör till autentiseringsförfarandet i avsnitt 4.3.

4.1.1

Kategorier

Kategoriseringen är inte helt entydig då vissa av kraven kan placeras i fler än en kategori. I de fallen har jag valt den kategori som jag tycker passar bäst för än- damålet och motiverar valet där jag tycker att det kan finnas tveksamheter. I ka- tegorin Säkerhet har jag valt att placera de egenskaper som i första hand handlar om vilka egenskaper systemet ska ha för att anses vara säkert. Egenskaperna i ka- tegorin Användarvänlighet har sitt ursprung i önskemål från slutanvändare. Dessa egenskaper avser att underlätta arbetet för användarna och berör inte säkerheten direkt, även om ett krångligt system indirekt kan bli mer osäkert då användarna lättare handhar det på ett felaktigt sätt. Det är alltså önskvärt att skapa ett använ- darvänligt system för att höja systemets säkerhetsnivå såväl som för att skapa en

Tabell 4.1.Översikt över önskade egenskaper

Benämning Kategori Prioritet

Något man har eller är Säkerhet Hög

Ej fast hemlighet Säkerhet Hög

Något man vet Säkerhet Hög

Hemlighet svår att komma åt Säkerhet Hög Något man måste bära med sig Säkerhet Mellan Borttagande låser arbetsstation Säkerhet Mellan Flera inloggningar Användarvänlighet Hög Flera behörigheter Användarvänlighet Hög Inget extra att bära på Användarvänlighet Mellan Växla identitet Användarvänlighet Mellan Snabb inloggning Användarvänlighet Mellan Single sign-on Användarvänlighet Mellan

Lokala konton Användarvänlighet Mellan

Lång inloggning Användarvänlighet Mellan Besöka arbetsstation Användarvänlighet Mellan

Gemensam profil Användarvänlighet Låg

Inloggning utan nätverk Användarvänlighet Låg Inkoppling av extern utrustning Användarvänlighet Låg Kompatibelt med Active Directory Övrigt Hög

Kompatibelt med CCM Övrigt Hög

Operativsystem Övrigt Hög

Support Övrigt Hög

Ingen extra hårdvara Övrigt Mellan

Pris Övrigt Låg

Källa: Egen konstruktion

bra arbetsmiljö för användarna. I kategorin Övrigt har jag placerat ickefunktionel- la egenskaper hos det önskade systemet.

4.1.2

Prioritetsnivåer

De prioritetsnivåer som jag valt att tilldela kraven ska tolkas som följer: • Hög

Dessa egenskaper är absoluta krav på det efterfrågade systemet. Produkter som inte kan uppfylla dessa krav är inte användbara för företaget.

• Mellan

Egenskaper med denna prioritet är högst önskvärda. Hur väl olika produk- ter uppfyller dessa krav kommer att ligga till grund för urvalet.

4.2 Beskrivning 21

• Låg

Dessa egenskaper är inte oviktiga men är inte avgörande för ett val av pro- dukt, dock kan de inverka i det eventuella fall då flera produkter i övrigt anses vara likvärdiga.

4.2

Beskrivning

I detta avsnitt ges en mer ingående beskrivning av de krav och egenskaper som nämns i tabell 4.1, ordnade efter kategorierna Säkerhet, Användarvänlighet samt Övrigt.

4.2.1

Säkerhet

Något man har eller är:

Detta krav finns eftersom en av förutsättningarna för projektet är att komma ifrån de inneboende problemen hos enbart lösenordsbaserade system. Genom att införa en hårdvaruenhet (”något man har”, till exempel ett smartkort eller liknande) som måste användas vid autentisering säkerställs det att det snabbt märks om någon obehörig har kommit över medel för autentisering. Alternativt kan identifikation genom biometri (”något man är”, till exempel fingeravtryck eller irismönster) in- föras. Nackdelen med biometri är dock att det inte märks om biometrisk informa- tion förfalskas, till skillnad från om en hårdvaruenhet skulle stjälas vilket märks då enheten saknas. Att förfalska biometrisk information anser jag dock vara myc- ket svårare än att till exempel komma över ett lösenord.

Hög prioritet motiveras med att detta krav är anledningen till att projektet genomförs.

Ej fast hemlighet:

En hemlig parameter som lagrats på en hårdvaruenhet måste kunna bytas utan att byta enhet. I fallet att något som lagrats på ett smartkort används direkt som lösenord vid autentisering får detta inte vara permanent, till exempel kortets seri- enummer. I detta fall skulle kortet motsvara ett vanligt lösenord som aldrig byts, vilket inte anses nog säkert. Det vore godtagbart att lagra användarens privata nyckel på enheten i händelse av en lösning baserad på asymmetriskt krypto eller digitala signaturer.

Hög prioritet motiveras med att systemet skulle kunna få en lägre säkerhets- nivå med en lösning där lösenord aldrig byts.

Något man vet:

Det får inte vara möjligt att bereda sig tillträde till resurser genom att stjäla en hårdvaruenhet eller att kopiera en hemlig parameter. Därför behöver systemet

innefatta även något användaren vet. Hårdvaruenheten måste därför användas tillsammans med ett lösenord, till exempel i form av en PIN-kod.

Hög prioritet motiveras med att ett system baserat enbart på hårdvaruenheter skulle kunna ge en lägre säkerhetsnivå än enbart lösenord, eftersom enheterna går att stjäla.

Hemlighet svår att komma åt:

I händelse av att en hårdvaruenhet kommer bort eller stjäls får det inte vara lätt att utvinna hemliga parametrar ur denna. Om lagrade lösenord eller en hemlig nyckel blir känd kan attackeraren utnyttja detta för att komma åt resurser och i det senare fallet även utge sig för att vara ägaren av kortet. Enheten måste vara tillräckligt skyddad mot hårdvaruattacker så att det inte är värt mödan för en obehörig att försöka sig på denna typ av attack.

Hög prioritet motiveras med att det skulle innebära stor skada om en hemlig parameter blev känd.

Något man måste bära med sig: