• No results found

Utvärdering av produkter för säker autentisering i Windowsmiljö

N/A
N/A
Protected

Academic year: 2021

Share "Utvärdering av produkter för säker autentisering i Windowsmiljö"

Copied!
104
0
0

Loading.... (view fulltext now)

Full text

(1)

Utvärdering av produkter för säker

autentisering i Windowsmiljö

Examensarbete utfört i Informationsteori vid Tekniska Högskolan i Linköping

av

Mattias Backman

Reg nr: LiTH-ISY-EX-3498-2004 Linköping 2004

(2)
(3)

Utvärdering av produkter för säker

autentisering i Windowsmiljö

Examensarbete utfört i Informationsteori vid Tekniska Högskolan i Linköping

av

Mattias Backman

Reg nr: LiTH-ISY-EX-3498-2004

Examinator: Viiveke Fåk Linköping 30 januari 2004.

(4)
(5)

Avdelning, Institution Division, Department Datum Date Språk Language 2 Svenska/Swedish 2 Engelska/English Rapporttyp Report category 2 Licentiatavhandling 2 Examensarbete 2 C-uppsats 2 D-uppsats 2 Övrig rapport URL för elektronisk version

ISBN

ISRN

Serietitel och serienummer Title of series, numbering

ISSN Titel Title Författare Author Sammanfattning Abstract Nyckelord Keywords

In this report hardware based alternatives to password authentication in a Windows domain are evaluated for the needs of a certain compa-ny. In order to investigate the demands on such alternatives interviews with people concerned have been carried out. The demands which re-sulted from the interviews have been used to select types of hardwa-re tokens for evaluation. Two products which offer authentication with smart cards and USB tokens have been selected and closer evaluated. These are RSA Passage which offers both hardware options and Rain-bow iKey which uses USB tokens. Both products are evaluated based on the demands and additional evaluation criteria. The information from the evaluations is used to compare the products.

Institutionen för Systemteknik

581 83 Linköping 2004-01-30

LITH-ISY-EX-3498-2004

http://www.ep.liu.se/exjobb/isy/2004/3498

Evaluation of secure authentication products in a Windows environ-ment

Utvärdering av produkter för säker autentisering i Windowsmiljö

Mattias Backman

× ×

datasäkerhet, autentisering, smartkort, digitala certifikat, Windows, PKI, PKCS, RSA, Passage, iKey.

(6)
(7)

Sammanfattning

I den här rapporten utvärderas hårdvarubaserade alternativ till autentisering med lösenord i en Windowsdomän för ett visst företags behov. För att utreda vilka krav som ska ställas på sådana alternativ har intervjuer med berörda personer ge-nomförts. Kraven som ställts upp som ett resultat av intervjuerna har använts för att välja ut typer av hårdvaruenheter för utvärdering. Två produkter som erbju-der autentisering med smartkort samt USB-enheter har valts ut och utvärerbju-derats närmare. Dessa är RSA Passage som erbjuder båda hårdvarualternativen samt Rainbow iKey som använder USB-enheter. Båda produkterna utvärderas med gångspunkt i kraven samt ytterligare bedömningskriterier. Informationen från ut-värderingarna används för att jämföra produkterna.

In this report hardware based alternatives to password authentication in a Win-dows domain are evaluated for the needs of a certain company. In order to inve-stigate the demands on such alternatives interviews with people concerned ha-ve been carried out. The demands which resulted from the interviews haha-ve been used to select types of hardware tokens for evaluation. Two products which offer authentication with smart cards and USB tokens have been selected and closer evaluated. These are RSA Passage which offers both hardware options and Rain-bow iKey which uses USB tokens. Both products are evaluated based on the de-mands and additional evaluation criteria. The information from the evaluations is used to compare the products.

Nyckelord: datasäkerhet, autentisering, smartkort, digitala certifikat, Windows, PKI, PKCS, RSA, Passage, iKey

(8)
(9)

Tackord

Jag vill tacka företaget för att jag fick möjligheten att göra mitt examensarbete där, vilket varit både roligt och mycket lärorikt. Särskilt tack till min handledare som varit ett stöd under arbetet och hjälpt mig med tips och uppmuntran. Dessutom vill jag tacka er som jag intervjuat för att ni tog er tid att svara på mina frågor. Ett stort tack till alla på avdelningen för visat intresse samt insikter om teckenspråk och mockajackans betydelse.

Från universitetet vill jag tacka min handledare Viiveke Fåk och min opponent Petter Larsson samt Erika Nilsson som korrekturläst rapporten. Ni hjälpte mig att höja kvaliteten på min rapport.

(10)
(11)

Ordförklaringar

Här beskrivs begrepp och förkortningar som används i rapporten. Se teorin i ka-pitel 2 för mer utförlig information om vissa begrepp.

3DES Triple DES. Utökning av DES-algoritmen. ACE-server Autentiseringsserver från RSA.

Active Directory Katalogtjänsten i ett Windows 2000-nätverk. Tillhandahåller central administrering av bland annat användarinformation. AES Advanced Encryption Standard.

CA Certification Authority

CAPI CryptoAPI. Här: Microsofts CAPI.

CCM On Command Comprehensive Client Management. Produkt som möjliggör fjärradministration av arbetsstationer. Tillgäng-liga funktioner är bl a installation och konfigurering av mjukvara och operativsystem samt hårddiskformattering och BIOS-uppdatering.

certifikat En datastruktur som binder en nyckel till ett subjekt. CIA Confidentiality, Integrity och Availability

CIP Cryptographic Interface Provider CSP Cryptographic Service Provider DES Data Encryption Standard

domän En grupp datorer i ett lokalt nätverk som kontrolleras av en domänserver.

FIPS Federal Information Processing Standards

GINA Står för Graphical Identification and Authorization och bety-der ett gränssnitt för valibety-dering av inloggningsuppgifter. Java Ett programspråk och körmiljö från Sun Microsystems.

Appli-kationer skrivna i Java är mycket portabla och kan bl a köras på inbäddade enheter som t ex smartkort.

(12)

på smartkort och andra enheter med starkt begränsat minne. LDAP Lightweight Directory Access Protocol

MD5 Message-Digest 5, kryptografisk hashfunktion. MMC Microsoft Management Console

MS CAPI Microsofts CryptoAPI

PC/SC Personal Computer Smart Card

PIN Personal Identification Number. Typiskt ett nummer på fyra till åtta siffror som innehavaren av ett kort eller dylikt skriver in för att visa sin behörighet att använda kortet.

PKCS Public-Key Cryptography Standards PKCS #11 Cryptographic Token Interface Standard

PKCS #15 Cryptographic Token Information Format Standard PKI Public Key Infrastructure

PKINIT Utökning av Kerberosprotokollet som möjliggör autentisering med publika nycklar.

Radius Remote Authentication Dial In User Service, ett protokoll för användarautentisering.

Remote Access Åtkomst till företagets nätverksresurser från extern plats. RS232 Standard för seriell kommunikation.

RSA Asymmetrisk kryptoalgoritm, namngiven efter upphovsmän-nen Rivest, Shamir och Adleman.

RSA Företaget RSA Security Inc. Grundades av Rivest, Shamir och Adleman 1982, då som RSA Data Security.

S/MIME Secure Multipurpose Internet Mail Extensions. Format för sä-ker e-post som använder X.509-certifikat.

SHA-1 Secure Hash Algorithm revision 1, kryptografisk hashfunktion.

Single sign-on Innebär att en utförd autentisering propageras till andra sy-stem eller att samma kontoinformation används i flera sysy-stem. SSO Se Single sign-on.

subjekt En person, en dator eller ett system i ett datornätverk. USB Universal Serial Bus

uttömmande sök-ning

Att pröva alla möjliga värden av ett lösenord eller meddelande för att hitta det rätta värdet.

(13)

Virtual Private Network

Ett virtuellt privat nätverk använder en öppen, distribuerad kommunikationskanal, som t ex Internet, för att säkert överfö-ra information mellan t ex företagsgrenar.

VPN Se Virtual Private Network. X.509 Standard för digitala certifikat.

(14)
(15)

Innehåll

1 Inledning 1 1.1 Uppdragsgivare . . . 1 1.2 Bakgrund . . . 1 1.3 Syfte och mål . . . 2 1.4 Källkritik . . . 2 1.5 Avgränsning . . . 3 1.6 Målgrupp . . . 3 1.7 Dokumentöversikt . . . 3 2 Teori 5 2.1 Datasäkerhet . . . 5 2.1.1 Definition . . . 5 2.1.2 Lösenord . . . 6

2.2 Public key infrastructure – PKI . . . 6

2.2.1 Kryptografi . . . 7

2.2.2 Digitala certifikat . . . 8

2.3 Standarder för kryptointegrering . . . 9

2.3.1 Public-Key Cryptography Standards – PKCS . . . 9

2.3.2 Microsoft CryptoAPI – MS CAPI . . . 10

2.3.3 PC/SC . . . 10

2.4 PKI i Windows 2000 . . . 11

2.4.1 Active Directory . . . 11

2.4.2 Kerberos och PKINIT . . . 11

2.4.3 Inloggning . . . 12 3 Metod 13 3.1 Arbetsgång . . . 13 3.2 Intervjuer . . . 14 3.3 Produktanalys . . . 15 3.4 Testarbete . . . 16 3.4.1 Testmiljö . . . 16 3.4.2 Genomförande av tester . . . 17 ix

(16)

4 Behov 19 4.1 Upplägg . . . 19 4.1.1 Kategorier . . . 19 4.1.2 Prioritetsnivåer . . . 20 4.2 Beskrivning . . . 21 4.2.1 Säkerhet . . . 21 4.2.2 Användarvänlighet . . . 22 4.2.3 Övrigt . . . 25 4.3 Övrig information . . . 26 4.3.1 PKI . . . 26 4.3.2 Uppstartsskydd . . . 27 4.3.3 Fysisk säkerhet . . . 27 4.3.4 Tjänstetillgänglighet . . . 27 5 Produkter 29 5.1 Kategorier . . . 29 5.1.1 Smartkort . . . 29 5.1.2 USB-enheter . . . 30 5.1.3 Fristående enheter . . . 31 5.1.4 GSM-telefon . . . 32 5.2 Gallring . . . 33 5.2.1 Smartkort . . . 34 5.2.2 USB-enheter . . . 34 5.2.3 Fristående enheter . . . 35 5.2.4 GSM-telefon . . . 35 5.3 Närmare analys . . . 35 5.3.1 Gemensamt . . . 36 5.3.2 RSA Passage . . . 36

5.3.3 SafeGuard Advanced Security . . . 37

5.3.4 Cryptocard SC-1 . . . 38 5.3.5 ActivCard . . . 38 5.3.6 Comex KT 9085 . . . 38 5.3.7 Rainbow iKey . . . 39 5.3.8 DigiSAFE KeyCrypt . . . 40 5.4 Resultat . . . 40

6 Test av RSA Passage 43 6.1 Allmänt . . . 43 6.1.1 Administration . . . 43 6.1.2 Användning . . . 46 6.2 Kravuppfyllnad . . . 49 6.2.1 Säkerhet . . . 49 6.2.2 Användarvänlighet . . . 50 6.2.3 Övrigt . . . 51 6.3 Övriga bedömningsgrunder . . . 51

(17)

Innehåll xi

6.3.1 Lämplighet för användare . . . 51

6.3.2 Lämplighet för företaget . . . 52

6.4 Sammanfattning av RSA Passage . . . 53

7 Test av Rainbow iKey 55 7.1 Allmänt . . . 55 7.1.1 Administration . . . 55 7.1.2 Användning . . . 57 7.2 Kravuppfyllnad . . . 59 7.2.1 Säkerhet . . . 59 7.2.2 Användarvänlighet . . . 59 7.2.3 Övrigt . . . 60 7.3 Övriga bedömningsgrunder . . . 61 7.3.1 Lämplighet för användare . . . 61 7.3.2 Lämplighet för företaget . . . 61

7.4 Sammanfattning av Rainbow iKey . . . 61

8 Jämförelse 63 8.1 Administration och användning . . . 63

8.2 Kravuppfyllnad . . . 63

8.3 Ytterligare funktionalitet . . . 65

9 Rekommendationer och slutsatser 67 9.1 Rekommendationer . . . 67

9.1.1 Val av produkt . . . 67

9.1.2 Införande av certfikatinloggning och PKI . . . 68

9.2 Slutsatser . . . 69

Litteraturförteckning 71 A Installation av nätverksserver 75 A.1 Översikt . . . 75

A.2 Konfiguration av komponenter . . . 75

A.2.1 Active Directory (rollen Domain Controller) . . . 76

A.2.2 DNS och DHCP . . . 76

A.2.3 Microsoft Management Console . . . 76

A.2.4 Certificate Services . . . 77

A.2.5 IIS . . . 78

A.2.6 POP3 och SMTP . . . 78

B Installation av RSA Passage 79 B.1 Installation av programvara . . . 79

B.1.1 Passage . . . 79

B.1.2 Drivrutiner . . . 80

B.1.3 Software token . . . 81

(18)

B.3 Konfigurering av Microsoft Outlook . . . 82

C Installation av Rainbow iKey 83 C.1 Installation av programvara . . . 83

C.1.1 Authentication Solution . . . 83

C.1.2 Client Software . . . 84

C.2 Konfigurering av domänpolicy . . . 84

C.3 Konfigurering av Microsoft Outlook . . . 84

Tabeller

3.1 Stödpunkter för produkturval . . . 16

4.1 Översikt över önskade egenskaper . . . 20

8.1 Jämförelse av kravuppfyllnad . . . 64

8.2 Jämförelse av tekniska specifikationer . . . 65

Figurer

2.1 Digital signering med message digest . . . 8

2.2 Den grundläggande CryptoAPI-modellen . . . 10

6.1 Control Center för Passage . . . 44

6.2 Certifikatlistan i Passage . . . 45

6.3 Utfärdande av certifikat att lagras på Passage-enhet . . . 46

6.4 Hantering av konton i Passage . . . 47

6.5 Hantering av lösenord i Passage . . . 48

7.1 Huvudvyn i Token Utilities för iKey . . . 56

7.2 Certifikatlistan för en iKey i Token Utilities . . . 57

7.3 Utfärdande av certifikat att lagras på iKey . . . 58

7.4 Windows GINA med stöd för smartkort . . . 58

7.5 Inmatning av PIN i Windows GINA . . . 59

A.1 MMC för hantering av servertjänster . . . 76

(19)

Kapitel 1

Inledning

I detta kapitel ges en introduktion till examensarbetet, dess syfte och mål, samt information avsedd att underlätta läsningen av dokumentet.

1.1

Uppdragsgivare

Uppdragsgivaren för detta projekt är en större organisation med höga krav på informationssäkerhet. Då projektet berör känsliga uppgifter som kan anses vara olämpliga att beskrivas i en offentlig rapport har uppdragsgivaren framfört öns-kemål om att inte nämnas vid namn i denna rapport. För att tillgodose detta har jag valt att hädanefter kalla uppdragsgivaren för företaget.

1.2

Bakgrund

På företaget finns ett stort antal stationära arbetsstationer, bärbara datorer och handdatorer. Arbetsstationerna är sammankopplade i ett Windowsbaserat nät-verk och användarna autentiseras i nätnät-verket genom att skriva sitt användarnamn och lösenord vid Windows inloggningsprompt (GINA). Användaridentiteten ve-rifieras och kopplas till ett användarkonto genom Active Directory. För att und-vika att aktuella lösenord blir kända av obehöriga tvingas användarna byta lö-senord regelbundet med korta intervall. När användaren lämnar sin arbetsstation ska den låsas så att ingen kan utnyttja den utan att kunna användarens eller en administratörs lösenord. Detta sker genom att användaren väljer att låsa arbets-stationen när han lämnar den, alternativt genom automatisk låsning, vilket sker efter en förutbestämd tid av inaktivitet.

Vissa användare utnyttjar resurser i nätverket utifrån, så kallad fjärråtkomst (eng. Remote Access), för att kunna utföra sin arbetsuppgifter från hemmet eller under tjänsteresor. För att skapa en VPN-tunnel mellan sig och företagets nätverk kontaktar dessa användare en särskild server som godkänner fjärranslutningen

(20)

och medger åtkomst till de resurser som användarna behöver. Denna server au-tentiserar användarna genom att de har en personlig SecurID SD600-dosa, som ger en engångskod vilken användaren tillsammans med sitt användarnamn och PIN-kod anger till VPN-servern. När servern godkänt användaren skapas en tun-nel till företagets nätverk och där får användaren logga in vid Windows GINA på samma sätt som beskrivits ovan. Servern som verifierar användarens externa autentisering består av en RSA ACE-server och idag köper företaget autentise-ringstjänsten för fjärråtkomst från en extern leverantör. Företaget kommer att gå över till att använda en intern server istället och även denna kommer att baseras på RSA ACE-programvara.

Företaget vill gå ifrån användandet av enbart lösenord för autentisering av an-vändare i det lokala nätverket. Detta därför att om ett lösenord blir känt är kontot öppet för exploatering samtidigt som det är svårt att veta om att lösenordet läckt ut. Det finns alltid en risk att användare väljer svaga lösenord som är enkla att komma ihåg eller skriver upp lösenordet i närheten av sin arbetstation, vilket gör att risken att någon obehörig kommer över lösenordet ökar. För att förenkla han-teringen av inloggningsmetoder och samtidigt göra det enklare för användarna att handha systemen är det dessutom önskvärt att finna ett enda system för au-tentisering som kan användas till alla typer av nätverksåtkomst, både extern och lokal. Detta är dock inte ett huvudmål med projektet.

1.3

Syfte och mål

Projektets syfte är att utreda vilka egenskaper ett system för säker autentisering bör ha, både ur användarnas och ur den tekniska personalens perspektiv. En eller flera produkter på marknaden, som har de önskade egenskaperna ska väljas ut för utvärdering och den eller de produkter som bedöms lämpliga för närmare analys ska installeras i ett testnätverk. Utifrån erfarenheterna från utvärdering och testinstallation ska rekommendationer för företagets val av produkt tas fram. Tonvikten ligger på lokal inloggning i företagets nätverk.

Målet med det här projektet är att utarbeta ett underlag åt företaget som ska kunna användas för beslut om vilken produkt eller vilka produkter som ska väljas att ersätta eller komplettera dagens system.

1.4

Källkritik

Majoriteten av den information som jag funnit om produkterna har sitt ursprung i tillverkarnas material i form av datablad och information på företagens webbsi-dor samt genom personlig kontakt med säljare och teknisk personal. Detta medför både att informationen inte kan anses vara objektiv och att den förändras ofta, ef-tersom produkterna hela tiden utvecklas vidare. Olika leverantörer presenterar tekniska specifikationer och andra fakta på olika sätt och med varierande detalj-nivå, vilket har försvårat arbetet med att jämföra produkterna rättvist.

(21)

1.5 Avgränsning 3

Underlaget till behovsanalysen är de intervjuer som utförts. Det är troligt att mer information kunnat samlas in om ett större antal intervjuer genomförts. Vida-re hade kanske andra behov uppdagats om urvalet av personal att intervjua gjorts annorlunda.

Vad gäller språket så har jag valt att skriva på svenska utan att använda eng-elska termer så långt det varit möjligt. Eftersom vedertagna begrepp inom detta område till stor del saknas i svenska språket, har jag översatt de engelska termer-na till motsvarigheter med så lika betydelser som möjligt. Jag är medveten om att det finns en risk att viss detaljnivå i dessa begrepp därmed förlorats.

1.5

Avgränsning

Djupare analyser av protokoll, algoritmer och teknologier ligger utanför omfatt-ningen av detta projekt. Där inte annat anges kommer jag därför att utgå från att kända protokoll och algoritmer är så säkra att de är användbara i sammanhang-et. Produkter på marknaden kommer jag att bedöma som säkra att använda om inga kända rapporter påvisar allvarliga brister och erfarenheten visar att hittills upptäckta fel rättats snabbt.

1.6

Målgrupp

Läsaren av denna rapport förväntas ha en grundläggande förståelse för arbete i nätverksmiljö och varför det är viktigt att användare autentiseras. Kännedom om grundläggande nätverksterminologi förutsätts och kännedom om operativsyste-met Microsoft Windows och dess begrepp underlättar. Grundläggande kunskaper i kryptoteori, speciellt asymmetrisk kryptering, underlättar men är inte nödvän-digt.

Innehållet i bilagorna är av mer detaljerad teknisk natur och är riktat till läsa-re med erfaläsa-renhet av nätverksadministration. Därför förklaras inte begläsa-repp och detaljer lika noga i bilagorna som i den övriga rapporten.

1.7

Dokumentöversikt

Här presenteras en översikt av dokumentet för att underlätta för läsare som är intresserade av specifika aspekter av projektet.

Kapitel 1 – Inledning Här ges bakgrunden till projektet och dess mål.

Kapitel 2 – Teori I detta kapitel presenteras den teoretiska bakgrunden till rap-porten. Grundläggande begrepp förklaras översiktligt och centrala begrepp för Windows PKI beskrivs mer ingående.

Kapitel 3 – Metod Här ges grunden för hur projektet var upplagt och planerat samt ingående beskrivningar av projektets centrala moment.

(22)

Kapitel 4 – Behov I detta kapitel redovisas de krav som ställs på produkter för autentisering, baserat på de intervjuer som genomförts.

Kapitel 5 – Produkter I detta kapitel redovisas de produkter som övervägts för utvärdering och valet av de produkter som ska testas närmare motiveras.

Kapitel 6 – Test av RSA Passage Här presenteras resultaten av utvärderingen av Passage.

Kapitel 7 – Test av Rainbow iKey Här presenteras resultaten av utvärderingen av iKey.

Kapitel 8 – Jämförelse I detta kapitel jämförs de två testade produkterna utgåen-de från kraven och andra kriterier.

Kapitel 9 – Rekommendationer och slutsatser Här presenteras rekommendatio-ner till företaget samt de slutsatser jag dragit.

Bilaga A – Installation av nätverksserver I denna bilaga redovisas hur servern i testnätverket var konfigurerad.

Bilaga B – Installation av RSA Passage I denna bilaga redovisas hur Passage in-stallerades och vilka anpassningar som gjordes.

Bilaga C – Installation av Rainbow iKey I denna bilaga redovisas hur iKey in-stallerades och vilka anpassningar som gjordes.

(23)

Kapitel 2

Teori

I det här kapitlet beskrivs den teoretiska bakgrund som ligger till grund för ex-amensarbetet. Avsikten är att ge den bakgrund som behövs för att läsaren ska kunna ta till sig det övriga innehållet i rapporten.

2.1

Datasäkerhet

Eftersom grundstenen i detta projekt är datasäkerhet, vilket är ett väldigt vagt be-grepp, ger jag i detta avsnitt en kort förklaring av begreppet samt lite relaterad bakgrund.

2.1.1

Definition

Den oftast föreslagna definitionen av datasäkerhet kommer från ITSEC (Informa-tion Technology Security Evalua(Informa-tion Criteria) [4] och omfattar tre aspekter. Dessa är confidentiality, integrity samt availability och brukar förkortas CIA. Confidentia-lity handlar om att förhindra att någon får tillgång till information utan tillåtelse. Det innebär både att läsa informationen direkt och att pussla ihop innehållet eller dra slutsatser om innehållet genom andra tillåtna åtgärder. Integrity handlar om att förhindra otillåten ändring av information. Man vill inte att någon ska kunna göra oönskade ändringar av befintlig information, ta bort information eller läg-ga till information som inte funnits från början. Availability innebär att tjänster ska finnas tillgängliga när de efterfrågas, utan onödiga fördröjningar. Ett sätt att skada en verksamhet är att överlasta till exempel ett nätverk och på så sätt göra det så långsamt att det blir omöjligt att utföra arbete. En risk med för restriktiva säkerhetsmekanismer är att tillgängligheten kan minska eftersom det kan leda till att användare hindras från att utföra sina arbetsuppgifter. [10]

Detta är en uppdelning som kan diskuteras och finslipas ytterligare men som är fullt tillräcklig som bakgrund till denna rapport.

(24)

2.1.2

Lösenord

Det finns relativt få datorsystem vars skydd inte innefattar lösenord i någon form. Det är dock av kostnadsskäl ofta det enda skyddet. Eftersom lösenord medför stora praktiska problem ska jag här beröra några av dessa.

Den första frågan är om användare kommer att äventyra systemets säkerhet genom att avslöja lösenordet till tredje part, oavsett om detta sker oavsiktligt eller medvetet. Ett av de allvarligaste praktiska hoten mot att hålla lösenord hemli-ga är så kallad social ingenjörskonst (eng. social engineering), vilket innebär att manipulera människorna som hanterar datorsystemen istället för att manipulera datorsystemen direkt. Att utge sig för att vara en auktoriserad person och begä-ra att få lösenorden är ofta ett enkelt sätt att få det. En undersökning, där uni-versitetsstuderande via e-post ombads att skicka in sitt lösenord för att validera lösenordsdatabasen, visade att ca 40 % av studenterna gjorde detta utan ifrågasät-tande och väldigt få anmälde utskicket till någon ansvarig [2]. En enklare attack, som ofta också fungerar, är att helt enkelt titta över axeln på en person som skriver in sitt lösenord.

Nästa mänskliga problem är att lösenord måste kunna skrivas in korrekt med tillräckligt stor sannolikhet. Ett långt, slumpmässigt lösenord kan förvirra använ-daren när det ska skrivas in, vilket kan vara allvarligt om använanvän-daren ska utföra något som är brådskande. [2]

Det sistnämnda berör det största problemet med lösenord, nämligen svårig-heter att komma ihåg dem. Lösenord får inte vara för uppenbara så att en tredje part lätt kan gissa eller söka rätt på dem. Födelsedagar och släktingars namn är exempel på dåliga lösenord. Inte heller ord som finns i vanligt språk bör använ-das eftersom en attackerare då kan pröva ord för ord från en ordlista för att hitta rätt lösenord. Eftersom användare idag tvingas använda lösenord på en mängd olika platser, till exempel på kontoret och olika webbplatser, ökar risken att de antingen skriver ner sina lösenord, även om de uppmanas att inte göra det, eller återanvänder lösenord i flera olika system. Risken finns då att lösenordet, som kanske räcker för att komma åt företagets nätverk, även blir känt av innehavaren av en hemsida på Internet där användaren använder detta lösenord. Om den som fått tillgång till ett lösenord har ont uppsåt skulle denne kunna pröva det kända lösenordet i företagets nätverk i hopp om att det fungerar där. [2]

Problemet i händelse av att ett lösenord blivit känt för någon obehörig är att chansen att upptäcka det är liten. Skulle en nyckel komma bort eller stjälas är det möjligt att byta låskolvar och om ett passerkort försvinner kan kortläsarna programmeras om, men att ett lösenord kommit på villovägar kanske inte märks förrän det utnyttjas i en attack.

2.2

Public key infrastructure – PKI

I detta avsnitt förklaras begreppet PKI och relaterade begrepp. Infrastruktur för publik nyckelhantering (PKI) är en uppsättning komponenter som hanterar

(25)

certi-2.2 Public key infrastructure – PKI 7

fikat och nycklar som används av tjänster för kryptering och digitala signaturer. En bra PKI tillhandahåller tjänster för kryptografiska operationer, utfärdande och återkallande av certifikat samt verktyg för att administrera allt detta. [12]

2.2.1

Kryptografi

Grunden för en PKI är, som namnet antyder, kryptering med publika nycklar. Det här avsnittet ger en kort bakgrund till de begrepp inom kryptoteori som behövs för att förstå denna rapport, detta utan att gå djupare in på matematiken bakom.

Symmetrisk kryptering

Symmetrisk kryptering innebär att kryptering och dekryptering av meddelanden sker med samma nyckel. Par av avsändare och mottagare delar en hemlig nyckel som de håller dold för andra än sig själva. Information som krypterats med en nyckel kan endast dekrypteras med samma nyckel. DES och utökningen 3DES (triple DES) är exempel på denna typ av algoritmer. [2]

Asymmetrisk kryptering

Asymmetrisk kryptering är en teknik som först identifierades av Diffie och Hell-man [7] och innebär att kryptering och dekryptering sker med separata nycklar. De två nycklarna är den privata nyckeln respektive den publika nyckeln vilka båda kan användas för att kryptera och dekryptera data. En användare ger sin publika nyckel till andra användare och behåller själv den privata nyckeln. In-formation som krypterats med den publika nyckeln kan endast dekrypteras med den privata nyckeln och vice versa. [2] RSA-algoritmen [23] är ett exempel på en asymmetrisk krypteringsalgoritm.

Signering

En algoritm för digital signering tar ett meddelande och skapar med hjälp av en privat nyckel ett nytt meddelande, signaturen, med ett antal speciella egenskaper. Dessa egenskaper innebär att det inte är möjligt att finna två meddelanden som ger samma signatur; att det inte är möjligt att finna ett meddelande med en gi-ven förutbestämd signatur och att det inte är möjligt att beräkna signaturen för ett givet meddelande utan att känna till den privata nyckeln. Det är vanligt att RSA-algoritmen används som signeringsalgoritm och då skapas signaturen ge-nom att meddelandet krypteras med den privata nyckeln. När mottagaren får det ursprungliga meddelandet tillsammans med signaturen dekrypterar denne sig-naturen med avsändarens publika nyckel och jämför resultatet med meddelan-det. Om den dekrypterade signaturen ger samma meddelande, kan mottagaren vara säker på att meddelandet inte ändrats på vägen samt att det verkligen skic-kats från den avsändaren som angivits. Eftersom både meddelandet och signatu-ren måste skickas och dessa har samma storleksordning, tar signerad information

(26)

dubbelt så stora resurser i anspråk jämfört med den ursprungliga informationen. Därför skapas oftast först en så kallad message digest som är ett hashvärde av med-delandet och det värdet krypteras därefter med den privata nyckeln och används som signatur, se figur 2.1. Hashvärdet skapas genom en så kallad hashfunktion, vilken från ett givet meddelande skapar ett värde som är unikt för det medde-landet och är mycket kortare än meddemedde-landet. Detta medför att om signaturen baseras på meddelandets hashvärde istället för på hela meddelandet så blir sig-naturen mycket kortare och därmed mindre kostsam att sända. En hashfunktion som ska användas i kryptografiska sammanhang har dessutom egenskaperna att det utifrån hashvärdet inte är möjligt att återskapa meddelandet och att det inte är möjligt att hitta två meddelanden som ger samma hashvärde. [2, 10]

Figur 2.1.Digital signering med message digest. Källa: [15] med egen översättning

MD5 är en kryptografisk hashfunktion som är speciellt avsedd för att använ-das i samband med digitala signaturer [21]. SHA-1 är ytterligare en hashalgoritm som till skillnad från MD5 skapar längre hashvärden och därmed är starkare mot uttömmande sökning men även är långsammare [29].

2.2.2

Digitala certifikat

Den som använder en publik nyckel ska kunna förlita sig på att den associerade privata nyckeln ägs av det subjekt (en person eller ett system) med vilket använ-daren vill använda en krypterings- eller signeringsmekanism. Förtroende för det-ta uppnås med digidet-tala certifikat, vilka är dadet-tastrukturer som kopplar samman publika nyckelvärden med subjekten. Att denna koppling är korrekt garanteras av en betrodd tredje part som digitalt signerar varje certifikat med sin egen nyc-kel. Denna betrodda part kallas certification authority (CA) och baserar sin garanti på till exempel ett skrivet avtal eller att subjektet presenterar sin privata nyckel för den CA som ska styrka certifikatets giltighet. [11] Vidare förutsätts att en CA endast utfärdar giltiga och pålitliga certifikat eftersom den är bunden av juridis-ka överenskommelser. Kryptografiskt skydd måste alltså i slutändan baseras på förtroende eller garantier utanför den kryptografiska världen. [10]

De centrala delarna av ett typiskt certifikat består av följande information: • subjektets publika nyckelvärde

(27)

2.3 Standarder för kryptointegrering 9

• giltighetstid

• utgivarens digitala signatur, som attesterar kopplingen mellan subjektets publika nyckel och subjektets identifieringsinformation. [2]

Det finns olika uppfattningar och standarder för hur certifikat ska se ut och vilka fält de ska innehålla. Den vedertagna standarden för digitala certifikat på Internet är X.509-standarden [11] som stöds av i princip alla applikationer som hanterar digitala certifikat.

För att kryptera meddelanden krävs, som skrevs i avsnitt 2.2.1, tillgång till mottagarens publika nyckel vilket innebär att avsändaren behöver mottagarens certifikat. Detsamma gäller för att kunna verifiera signerade meddelanden som skickats från den personen. Att ha tillgång till en användares certifikat innebär ingen minskad säkerhet för användaren eftersom certifikatet endast innehåller publik nyckelinformation. Med bara ett certifikat kan ingen annan signera medde-landen och därmed utge sig för att vara certifikatets ägare, eller dekryptera med-delanden som är avsedda för den användaren. Den kryptografiska bakgrunden till detta finns beskriven i avsnitt 2.2.1.

2.3

Standarder för kryptointegrering

I det här avsnittet beskrivs kortfattat de mest relevanta abstraktionslagren som används för att integrera kryptografiska enheter med Windows och andra system.

2.3.1

Public-Key Cryptography Standards – PKCS

Public-Key Cryptography Standards är en uppsättning specifikationer som pro-ducerats av RSA i samarbete med utvecklare världen över och har fått stor sprid-ning samt har blivit industristandard. Specifikationerna har skapats eftersom an-vändandet av kryptering baserat på publika nycklar fått fäste och tillämpas allt mer. För att denna teknik ska kunna användas så effektivt som möjligt krävs att olika implementationer kan fungera tillsammans, oavsett vilken underliggande teknik som används. Avsikten med PKCS är att tillhandahålla en grund för att låta olika PKI-implementationer fungera med varandra. [25]

Det elfte standarddokumentet, PKCS #11 är det som är mest relevant för detta projekt. Det definierar Cryptographic Token Interface Standard som alltså specifice-rar gränssnitt mot kryptografiska hårdvaruenheter. PKCS #11 syftar till att göra gränssnittet oberoende av vilken hårdvara som används och ge applikationer en gemensam logisk bild av enheten. Gränssnittet används av många tillverkare av PKI-lösningar för att integrera hårdvaruenheter för digitala certifikat samt lagring och generering av kyptonycklar. [24]

(28)

2.3.2

Microsoft CryptoAPI – MS CAPI

MS CAPI är ett högnivågränssnitt mellan Windowsapplikationer och en kärna för kryptografisk funktionalitet, som är grunden för säkerhetsimplementationer i Microsoft Windows. Gränssnittet ger alla applikationer tillgång till säkerhetsfunk-tioner utan att applikasäkerhetsfunk-tionerna behöver bry sig om kryptoalgoritmer, privata eller publika nycklar och andra lågnivådetaljer. CAPI i sin tur anropar så kallade Cryp-tographic Service Providers, CSP, moduler vilka utför arbetet med att kryptera och dekryptera data. Se figur 2.2 för en överblick över detta, där visas hur CAPI lig-ger mellan applikationen och CSP:n och utför de operationer som applikationen begär.

Figur 2.2.Den grundläggande CryptoAPI-modellen. Källa: [9]

En CSP kan vara mjukvara som är en del av operativsystemet men kan även bestå till exempel av en kryptografisk enhet i form av ett smartkort. I det senare fallet anropar CAPI den CSP som tillhandahålls av kortet och kryptooperationer-na sker internt i den enheten. [9]

2.3.3

PC/SC

PC/SC-standarden specificerar gränssnitt mellan kortläsare och datorer. Målet med standarden är att smartkort, kortläsare och datorer från olika tillverkare ska fungera tillsammans. Med hjälp av denna standard fungerar CSP:er och appli-kationer med standardläsare utan att tvingas skrivas med tanke på till exempel vilken typ av anslutning som används mellan läsare och dator. Dessutom behö-ver inte en applikation skrivas specifikt för en viss typ av kortläsare med risk för att applikationen inte fungerar med framtida läsare. Microsoft har implementerat PC/SC-standarden i Windowsoperativsystemen. [18]

(29)

2.4 PKI i Windows 2000 11

2.4

PKI i Windows 2000

I detta avsnitt redogörs för några koncept som är viktiga för att förstå hur inlogg-ning med smartkort fungerar i Windows 2000.

2.4.1

Active Directory

Tjänsten Active Directory är en central komponent av Windowsplattformen och tillhandahåller medel för hantering av de identiteter och relationer som bygger upp nätverksmiljöer. Databasen som informationen lagras i kallas ofta katalogen. Den innehåller information om objekt som användare, användargrupper, datorer, domäner, avdelningar i organisationen samt säkerhetspolicyer. Katalogen lagras på servrar som kallas domänkontrollanter och används av nätverksapplikationer och tjänster. Säkerhet integreras i Active Directory genom autentisering vid in-loggning och åtkomstkontroll till objekt i katalogen. Genom en enda inin-loggning kan administratörer hantera data i katalogen och auktoriserade användare kan komma åt resurser. Active Directory lagrar information om användarkonton och grupper tillsammans med åtkomsträttigheter för dessa. Därför får en användare som loggar in i domänen både autentisering och auktorisering att komma åt re-surser i systemet. Som ett exempel autentiseras en användare som loggar in med information som lagrats i katalogen och senare, när användaren försöker komma åt en tjänst i nätverket, kontrollerar systemet egenskaperna för åtkomst som de-finierats i katalogen för den tjänsten. I Active Directory lagras även de certifikat som används för inloggning med smartkort och certifikat för till exempel säker e-post publiseras så att användare i domänen kan verifiera avsändare. [13]

2.4.2

Kerberos och PKINIT

Windows 2000 använder Kerberosprotokollet, version 5, för ömsesidig autentise-ring av klienter och servrar. Kerberosprotokollet förlitar sig på en autentiseautentise-rings- autentiserings-teknik som baseras på delade hemligheter. Grundkonceptet är att om en hemlig-het är känd av endast två personer så kan endera personen verifiera den andres identitet genom att bekräfta att denne känner till hemligheten. I Kerberos består hemligheten av en symmetrisk kryptografisk nyckel och den ena parten bevisar att denne innehar hemligheten genom att kryptera ett meddelande, den andre ge-nom att dekryptera det. Kerberos använder Active Directory som kontodatabas varifrån information om användare och maskiner hämtas. [12]

Det finns en föreslagen utökning till Kerberos som kallas PKINIT, vilken möj-liggör användandet av digitala certifikat istället för lösenord under den första au-tentiseringen. Denna utökning är grunden för stödet för inloggning med smart-kort i Windows 2000. [12] Implementationen av PKINIT i Windows 2000 baseras på utkast 9 av standardförslaget [30] och Microsoft kommer att revidera imple-mentationen när förslaget antagits som standard [14].

(30)

2.4.3

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]

(31)

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 sbesö-kapade jag mig en bild av de produkter som finns tillgängliga på marknaden och inhämtade information om dem.

(32)

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.

(33)

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 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.

(34)

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.

(35)

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 krocmins-kar 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.

(36)
(37)

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örfakomplette-randet 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

(38)

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.

(39)

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

(40)

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:

För att minimera risken för att hårdvaruenheter stjäls är det viktigt att använda-ren inte lämnar sin enhet utan uppsikt, utan tar med sig enheten när han eller hon lämnar sin arbetsstation. Det är önskvärt att enheten består av något som använ-daren alltid behöver ha med sig, till exempel för identifikation eller inpassering.

Mellanprioritet motiveras med att detta skulle minska risken att enheterna lämnas utan uppsikt.

Borttagande låser arbetsstation:

För att säkerställa att arbetsstationen verkligen låses när användaren lämnar den är det önskvärt att detta sker automatiskt. Idag sker detta efter en förutbestämd tid av inaktivitet, vilket inte är idealiskt ur säkerhetssynpunkt eftersom datorn då kommer att stå olåst under denna tid. Tiden kan inte heller väljas allt för kort ef-tersom användare då tvingas att låsa upp datorn ofta, vilket fördröjer deras arbete. Alla användare låser heller inte sin arbetsstation manuellt varje gång de lämnar den. En lösning på detta vore att tillse att arbetsstationen låses så fort hårdvaru-enheten avlägsnas från den.

Mellanprioritet motiveras med att detta avsevärt skulle minska risken att ar-betsstationer lämnas olåsta utan uppsikt.

4.2.2

Användarvänlighet

Flera inloggningar:

Vissa användare har behov av att vara inloggade på flera arbetsstationer samti-digt. Att logga in på ytterligare datorer får alltså inte påverka inloggning som redan gjorts på annan dator.

(41)

4.2 Beskrivning 23

Hög prioritet motiveras med att om detta inte fungerar kommer vissa använ-dare att hämmas i sitt arbete.

Flera behörigheter:

Vissa användare har olika behörigheter i nätverket. Till exempel kan en administ-ratör ha rollen som vanlig användare samt som användare med administadminist-ratörs- administratörs-rättigheter. Vid olika tillfällen behöver användaren logga in med olika roller för att lösa de olika uppgifter som åligger honom. Systemet måste alltså tillåta att en individ kan ha olika roller i nätverket.

Hög prioritet motiveras med att om detta inte fungerar kommer vissa använ-dare att hämmas i sitt arbete.

Inget extra att bära på:

Användare vill inte tvingas att bära med sig för många extra saker. Därför bör det inte krävas olika hårdvaruenheter för att välja att använda olika behörigheter. Det bör alltså vara möjligt att logga in på olika konton med hjälp av en enda enhet. Det är även önskvärt att samma hårdvaruenhet ska kunna användas både för lokal inloggning och fjärrinloggning.

Mellanprioritet motiveras med att detta skulle underlätta arbetet för många användare.

Växla identitet:

Det är önskvärt att användare med flera behörigheter ska kunna byta till en an-nan användaridentitet för att utföra uppgifter som kräver anan-nan behörighet än den för tillfället inloggade användaridentiteten medger. För att inte vara tvungen att avsluta pågående session bör detta kunna utföras utan att användaren måste logga ut och in med annan identitet.

Mellanprioritet motiveras med att detta skulle underlätta arbetet för vissa an-vändare.

Snabb inloggning:

Det är önskvärt att proceduren för autentisering med hårdvaruenheterna är enkel och snabb att genomföra. Vissa användare måste, som en del av sitt dagliga ar-bete, logga ut och in väldigt ofta. Dessa användare skulle hindras i sitt arbete om inloggningsförfarandet vore omständigt och långsamt.

Mellanprioritet motiveras med att detta skulle underlätta arbetet för vissa an-vändare.

Single sign-on:

För att underlätta för användare som behöver autentisera sig mot flera olika sy-stem vore det önskvärt om samma autentiseringsuppgifter kunde användas i

(42)

samt-liga system. Det kan till exempel ordnas så att olika applikationer använder sam-ma användardatabas, eller att applikationerna förstår att användaren är autenti-serad på sin arbetsstation och därmed medges åtkomst automatiskt.

För stor integration av olika system kan dock medföra säkerhetsrisker varför det måste övervägas noga hur omfattande och på vilket sätt single sign-on ska införas.

Mellanprioritet motiveras med att detta skulle underlätta arbetet för vissa an-vändare. Kravet på SSO minskar om kraven på snabb inloggning och behörighets-byte uppfylls väl.

Lokala konton:

Vissa användare har behov av att ha tillgång till lokala konton, det vill säga an-vändarkonton som bara gäller på den lokala arbetsstationen och inte i nätverket i övrigt. Ett nytt system måste tillåta även sådana konton.

Mellanprioritet motiveras med att om detta inte fungerar skulle vissa använ-dare hindras i sitt arbete.

Lång inloggning:

Vissa användare loggar ibland in på en arbetsstation och behöver vara inloggad under lång tid, typiskt flera dygn. Ett nytt system får inte begränsa den tid en användare kan vara inloggad på en arbetsstation.

Mellanprioritet motiveras med att om detta inte fungerar skulle vissa använ-dare hindras i sitt arbete.

Besöka arbetsstation:

Vissa användare behöver logga in på en arbetsstation för att starta en uppgift och lämnar sedan denna varvid arbetsstationen låses. Andra användare kan sedan be-höva låsa upp arbetsstationen för att fortsätta uppgiften eller övervaka den. Detta ska kunna ske utan att den första användaren loggas ut och uppgiften därmed avbryts.

Mellanprioritet motiveras med att detta skulle underlätta arbetet för vissa an-vändare.

Gemensam profil:

Vissa användare har behov av att ha exakt samma miljö på sin arbetsstation som andra användare har. Till exempel genom att dela på ett användarkonto.

Låg prioritet motiveras med att detta kan lösas genom att upprätthålla iden-tiska användarprofiler om inte produkterna stödjer detta.

(43)

4.2 Beskrivning 25 Inloggning utan nätverk:

I händelse av nätverksproblem eller att en arbetsstation kopplats bort från nät-verket är det idag möjligt att ändå logga in på de senast använda domänkontona. Detta sker genom att Windows 2000 sparar information om använda konton. Det skulle underlätta arbetet om detta fungerar även med ett nytt system.

Låg prioritet motiveras med att det inte anses viktigt nog att påverka valet av produkt.

Inkoppling av extern utrustning:

På en avdelning finns behov av att koppla in datorutrustning som inte kommer från företaget på företagets nätverk för att utföra tester. Idag sker detta både i det primära nätverket och i ett separat nätverk på den aktuella avdelningen.

Låg prioritet motiveras med att detta kan uppnås genom att enbart koppla in utrustningen i det separata nätverket om inte produkterna stöder detta.

4.2.3

Övrigt

Kompatibelt med Active Directory:

Företaget administrerar användarkonton genom Active Directory och detta måste fungera även med ett nytt system för användarautentisering.

Hög prioritet motiveras med att om inte produkten kan fungera i den nuva-rande miljön är den inte användbar för företaget.

Kompatibelt med CCM:

Företaget administrerar sina arbetsstationer och servrar genom On Command CCM. Användandet av CCM innebär bland annat att datorer måste kunna fjärr-startas och det måste vara möjligt att logga in på datorerna från nätverket med vissa konton.

Hög prioritet motiveras med att om inte produkten kan fungera i den nuva-rande miljön är den inte användbar för företaget.

Operativsystem:

Produkten ska fungera i ett nätverk baserat på Microsoft Windows. Operativsy-stem på arbetsstationer är Windows 2000 och Windows XP, på servrar Windows 2000 och 2003.

Hög prioritet motiveras med att om inte produkten kan fungera i den nuva-rande miljön är den inte användbar för företaget.

(44)

Support:

Det är viktigt att företaget som levererar produkten har en bra organisation där det går snabbt att få hjälp i händelse av problem och där eventuella brister i pro-dukten som uppdagas åtgärdas snabbt. Detta är viktigt både för säkerheten och för att minska kostnader i händelse av problem.

Hög prioritet motiveras med att om bra support saknas finns det risk att före-taget tvingas lägga mycket resurser på att åtgärda problem eller blir fast med en produkt som inte fungerar eller har säkerhetsbrister.

Ingen extra hårdvara:

Det är en fördel om lösningen inte kräver att extra hårdvara, till exempel läsare för smartkort, installeras på arbetsstationerna. Detta skulle minska både kostnader och administration. Det skulle även vara användbart vid arbete från persondator i hemmet eller från bärbar dator.

Mellanprioritet motiveras med att detta skulle förenkla hanteringen av pro-dukten.

Pris:

Det är naturligtvis önskvärt att kostnaden för inköp av licenser, hårdvaruenheter och kringutrustning är så låg som möjligt.

Låg prioritet motiveras med att det viktigaste är att anskaffa ett så bra system som möjligt, priset är inte den avgörande faktorn.

4.3

Övrig information

I detta avsnitt finns ytterligare information om företagets behov samt önskemål som framkommit under behovsanalysen. Detta gäller bland annat funktionalitet som ger mervärden utöver autentiseringsfunktioner hos det nya systemet. Pro-dukter är mer intressanta om de redan nu stöder sådan funktionalitet och bör heller inte motverka att sådan funktionalitet införs i ett senare skede. Här finns även några punkter som kan vara relevanta vid en jämförelse eller beslut.

4.3.1

PKI

För att kunna signera och kryptera e-post och andra elektroniska dokument är fö-retaget intresserat av att införa en infrastruktur för asymmetrisk nyckelhantering, en så kallad public key infrastructure eller PKI. En autentiseringslösning som base-ras på digitala certifikat skulle kunna dra nytta av en eventuell kommande PKI, vilket skulle kunna minska kostnader i form av bland annat minskade administ-rationsresurser. Eftersom ett av grundkraven för ett nytt autentiseringssystem är att det ska innefatta en hårdvaruenhet, skulle denna enhet kunna användas till att även lagra certifikat för signering och kryptering om produkten medger detta.

References

Related documents

Bredbandsnäten används idag primärt för kommersiella tillämpningar som Internet, IP-telefoni och IPTV, men inom kort kommer näten att användas för ytterligare till-

Leverantören av en tjänst eller lösning för säkra mejl måste därför leva upp till dem.. Inte bara

Du måste logga ut och välja ett lösenord eller spara en cookie för att kunna öppna ett meddelande som har skickats utan kod på nytt. Sparar du ett lösenord kan meddelandet

Syftet är att utreda om metoden säker spolning kan bli en metod för Uppsala Vatten att använda vid spolningar av spillvattenledningar inom områden där det finns förorenat

För att förbättra förutsättningar för att fler ska välja cykel före personbil fokuseras insatser främst till ett systematiskt arbete i samverkan mellan staten och de 50

NTF har träffat föräldrar på föräldramöten och föräldraråd för att ha en dialog om barnens skolväg, fördelarna med cykling och varför föräldrarna inte ska skjutsa sina

Två tidigare strategier kring cykling finns framtagna och en viktig utgångspunkt i arbetet med denna strategi är att analysera de tidigare strategierna, vad som faktiskt

Organ för Riksförbundet för Hjärt- och Lungsjuka Ansv. Prenumerationspris: Helår 20: — , halvår 11:— UR INNEHÅLLET: NYA SMITTSKYDDSLAGEN 6 LÖNESÄTTNING vid