Utvärdering av produkter för säker autentisering i ...19491/FULLTEXT01.pdf · with people concerned have been carried out. The demands which re-sulted from the interviews have

Utvärdering av produkter för säkerautentisering i Windowsmiljö

Examensarbete utfört i Informationsteorivid Tekniska Högskolan i Linköping

av

Mattias Backman

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

Utvärdering av produkter för säkerautentisering i Windowsmiljö

Examensarbete utfört i Informationsteorivid 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.

Avdelning, InstitutionDivision, Department

DatumDate

Språk

Language

2 Svenska/Swedish

2 Engelska/English

RapporttypReport category

2 Licentiatavhandling

2 Examensarbete

2 C-uppsats

2 D-uppsats

2 Övrig rapport

URL för elektronisk version

ISBN

ISRN

Serietitel och serienummerTitle of series, numbering

ISSN

Titel

Title

FörfattareAuthor

SammanfattningAbstract

NyckelordKeywords

In this report hardware based alternatives to password authenticationin a Windows domain are evaluated for the needs of a certain compa-ny. In order to investigate the demands on such alternatives interviewswith 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 withsmart 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 onthe demands and additional evaluation criteria. The information fromthe evaluations is used to compare the products.

Institutionen för Systemteknik581 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.

Sammanfattning

I den här rapporten utvärderas hårdvarubaserade alternativ till autentisering medlösenord i en Windowsdomän för ett visst företags behov. För att utreda vilkakrav 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öratt 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ärderatsnärmare. Dessa är RSA Passage som erbjuder båda hårdvarualternativen samtRainbow iKey som använder USB-enheter. Båda produkterna utvärderas med ut-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 have beenused to select types of hardware tokens for evaluation. Two products which offerauthentication with smart cards and USB tokens have been selected and closerevaluated. 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 isused to compare the products.

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

i

ii

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 somvarit ett stöd under arbetet och hjälpt mig med tips och uppmuntran. Dessutomvill jag tacka er som jag intervjuat för att ni tog er tid att svara på mina frågor. Ettstort tack till alla på avdelningen för visat intresse samt insikter om teckenspråkoch mockajackans betydelse.

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

iii

iv

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 AuthorityCAPI 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 avmjukvara och operativsystem samt hårddiskformattering ochBIOS-uppdatering.

certifikat En datastruktur som binder en nyckel till ett subjekt.CIA Confidentiality, Integrity och AvailabilityCIP Cryptographic Interface ProviderCSP Cryptographic Service ProviderDES Data Encryption Standarddomän En grupp datorer i ett lokalt nätverk som kontrolleras av en

domänserver.FIPS Federal Information Processing StandardsGINA Står för Graphical Identification and Authorization och bety-

der ett gränssnitt för validering 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öraspå inbäddade enheter som t ex smartkort.

v

Javacard Specifikation som möjliggör exekvering av Java-applikationerpå smartkort och andra enheter med starkt begränsat minne.

LDAP Lightweight Directory Access ProtocolMD5 Message-Digest 5, kryptografisk hashfunktion.MMC Microsoft Management ConsoleMS CAPI Microsofts CryptoAPIPC/SC Personal Computer Smart CardPIN Personal Identification Number. Typiskt ett nummer på fyra

till åtta siffror som innehavaren av ett kort eller dylikt skriverin för att visa sin behörighet att använda kortet.

PKCS Public-Key Cryptography StandardsPKCS #11 Cryptographic Token Interface StandardPKCS #15 Cryptographic Token Information Format StandardPKI Public Key InfrastructurePKINIT 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 system.SSO Se Single sign-on.subjekt En person, en dator eller ett system i ett datornätverk.USB Universal Serial Busuttömmande sök-ning

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

vi

Virtual PrivateNetwork

Ett virtuellt privat nätverk använder en öppen, distribueradkommunikationskanal, 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.

vii

viii

Innehåll

1 Inledning 11.1 Uppdragsgivare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Källkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Avgränsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Målgrupp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Dokumentöversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Teori 52.1 Datasäkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Lösenord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Public key infrastructure – PKI . . . . . . . . . . . . . . . . . . . . . 62.2.1 Kryptografi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Digitala certifikat . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Standarder för kryptointegrering . . . . . . . . . . . . . . . . . . . . 92.3.1 Public-Key Cryptography Standards – PKCS . . . . . . . . . 92.3.2 Microsoft CryptoAPI – MS CAPI . . . . . . . . . . . . . . . . 102.3.3 PC/SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 PKI i Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.1 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2 Kerberos och PKINIT . . . . . . . . . . . . . . . . . . . . . . . 112.4.3 Inloggning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Metod 133.1 Arbetsgång . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Intervjuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Produktanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Testarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1 Testmiljö . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Genomförande av tester . . . . . . . . . . . . . . . . . . . . . 17

ix

x Innehåll

4 Behov 194.1 Upplägg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Kategorier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Prioritetsnivåer . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Beskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.1 Säkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2 Användarvänlighet . . . . . . . . . . . . . . . . . . . . . . . . 224.2.3 Övrigt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Övrig information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.1 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.2 Uppstartsskydd . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.3 Fysisk säkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.4 Tjänstetillgänglighet . . . . . . . . . . . . . . . . . . . . . . . 27

5 Produkter 295.1 Kategorier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Smartkort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2 USB-enheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.3 Fristående enheter . . . . . . . . . . . . . . . . . . . . . . . . 315.1.4 GSM-telefon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 Gallring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.1 Smartkort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2.2 USB-enheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2.3 Fristående enheter . . . . . . . . . . . . . . . . . . . . . . . . 355.2.4 GSM-telefon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3 Närmare analys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3.1 Gemensamt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3.2 RSA Passage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3.3 SafeGuard Advanced Security . . . . . . . . . . . . . . . . . 375.3.4 Cryptocard SC-1 . . . . . . . . . . . . . . . . . . . . . . . . . 385.3.5 ActivCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3.6 Comex KT 9085 . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3.7 Rainbow iKey . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3.8 DigiSAFE KeyCrypt . . . . . . . . . . . . . . . . . . . . . . . 40

5.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Test av RSA Passage 436.1 Allmänt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1.1 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1.2 Användning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 Kravuppfyllnad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2.1 Säkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2.2 Användarvänlighet . . . . . . . . . . . . . . . . . . . . . . . . 506.2.3 Övrigt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.3 Övriga bedömningsgrunder . . . . . . . . . . . . . . . . . . . . . . . 51

Innehåll xi

6.3.1 Lämplighet för användare . . . . . . . . . . . . . . . . . . . . 516.3.2 Lämplighet för företaget . . . . . . . . . . . . . . . . . . . . . 52

6.4 Sammanfattning av RSA Passage . . . . . . . . . . . . . . . . . . . . 53

7 Test av Rainbow iKey 557.1 Allmänt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.1.1 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . 557.1.2 Användning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Kravuppfyllnad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.2.1 Säkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.2.2 Användarvänlighet . . . . . . . . . . . . . . . . . . . . . . . . 597.2.3 Övrigt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3 Övriga bedömningsgrunder . . . . . . . . . . . . . . . . . . . . . . . 617.3.1 Lämplighet för användare . . . . . . . . . . . . . . . . . . . . 617.3.2 Lämplighet för företaget . . . . . . . . . . . . . . . . . . . . . 61

7.4 Sammanfattning av Rainbow iKey . . . . . . . . . . . . . . . . . . . 61

8 Jämförelse 638.1 Administration och användning . . . . . . . . . . . . . . . . . . . . 638.2 Kravuppfyllnad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.3 Ytterligare funktionalitet . . . . . . . . . . . . . . . . . . . . . . . . . 65

9 Rekommendationer och slutsatser 679.1 Rekommendationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

9.1.1 Val av produkt . . . . . . . . . . . . . . . . . . . . . . . . . . 679.1.2 Införande av certfikatinloggning och PKI . . . . . . . . . . . 68

9.2 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Litteraturförteckning 71

A Installation av nätverksserver 75A.1 Översikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.2 Konfiguration av komponenter . . . . . . . . . . . . . . . . . . . . . 75

A.2.1 Active Directory (rollen Domain Controller) . . . . . . . . . 76A.2.2 DNS och DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 76A.2.3 Microsoft Management Console . . . . . . . . . . . . . . . . 76A.2.4 Certificate Services . . . . . . . . . . . . . . . . . . . . . . . . 77A.2.5 IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.2.6 POP3 och SMTP . . . . . . . . . . . . . . . . . . . . . . . . . 78

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

B.1.1 Passage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.1.2 Drivrutiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80B.1.3 Software token . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B.2 Konfigurering av domänpolicy . . . . . . . . . . . . . . . . . . . . . 81

xii Innehåll

B.3 Konfigurering av Microsoft Outlook . . . . . . . . . . . . . . . . . . 82

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

C.1.1 Authentication Solution . . . . . . . . . . . . . . . . . . . . . 83C.1.2 Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . 84

C.2 Konfigurering av domänpolicy . . . . . . . . . . . . . . . . . . . . . 84C.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 . . . . . . . . . . . . . . . . . . . . . . 648.2 Jämförelse av tekniska specifikationer . . . . . . . . . . . . . . . . . 65

Figurer

2.1 Digital signering med message digest . . . . . . . . . . . . . . . . . 82.2 Den grundläggande CryptoAPI-modellen . . . . . . . . . . . . . . . 10

6.1 Control Center för Passage . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Certifikatlistan i Passage . . . . . . . . . . . . . . . . . . . . . . . . . 456.3 Utfärdande av certifikat att lagras på Passage-enhet . . . . . . . . . 466.4 Hantering av konton i Passage . . . . . . . . . . . . . . . . . . . . . 476.5 Hantering av lösenord i Passage . . . . . . . . . . . . . . . . . . . . 48

7.1 Huvudvyn i Token Utilities för iKey . . . . . . . . . . . . . . . . . . 567.2 Certifikatlistan för en iKey i Token Utilities . . . . . . . . . . . . . . 577.3 Utfärdande av certifikat att lagras på iKey . . . . . . . . . . . . . . . 587.4 Windows GINA med stöd för smartkort . . . . . . . . . . . . . . . . 587.5 Inmatning av PIN i Windows GINA . . . . . . . . . . . . . . . . . . 59

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

B.1 Konfiguration under installationen av Passage . . . . . . . . . . . . 80

Kapitel 1

Inledning

I detta kapitel ges en introduktion till examensarbetet, dess syfte och mål, samtinformation 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 varaolä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 harjag 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 ochhanddatorer. Arbetsstationerna är sammankopplade i ett Windowsbaserat nät-verk och användarna autentiseras i nätverket genom att skriva sitt användarnamnoch 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 arbetsstationska den låsas så att ingen kan utnyttja den utan att kunna användarens eller enadministratö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 skerefter 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 ellerunder tjänsteresor. För att skapa en VPN-tunnel mellan sig och företagets nätverkkontaktar dessa användare en särskild server som godkänner fjärranslutningen

1

2 Inledning

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, somger en engångskod vilken användaren tillsammans med sitt användarnamn ochPIN-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 GINApå samma sätt som beskrivits ovan. Servern som verifierar användarens externaautentisering 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 baseraspå 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äcktut. Det finns alltid en risk att användare väljer svaga lösenord som är enkla attkomma ihåg eller skriver upp lösenordet i närheten av sin arbetstation, vilket göratt 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ändarnaatt 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 ochlokal. 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 autentiseringbör ha, både ur användarnas och ur den tekniska personalens perspektiv. En ellerflera produkter på marknaden, som har de önskade egenskaperna ska väljas utför utvärdering och den eller de produkter som bedöms lämpliga för närmareanalys ska installeras i ett testnätverk. Utifrån erfarenheterna från utvärderingoch 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 skakunna användas för beslut om vilken produkt eller vilka produkter som ska väljasatt ersätta eller komplettera dagens system.

1.4 Källkritik

Majoriteten av den information som jag funnit om produkterna har sitt ursprungi 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örbå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 presenterartekniska 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.

1.5 Avgränsning 3

Underlaget till behovsanalysen är de intervjuer som utförts. Det är troligt attmer 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 gjortsannorlunda.

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 dettaområ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 attdet 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 attkä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 ominga kända rapporter påvisar allvarliga brister och erfarenheten visar att hittillsupptä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 inätverksmiljö och varför det är viktigt att användare autentiseras. Kännedom omgrundläggande nätverksterminologi förutsätts och kännedom om operativsyste-met Microsoft Windows och dess begrepp underlättar. Grundläggande kunskaperi 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 erfarenhet av nätverksadministration. Därför förklaras inte begrepp ochdetaljer 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 ärintresserade 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 begreppför Windows PKI beskrivs mer ingående.

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

4 Inledning

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

Kapitel 5 – Produkter I detta kapitel redovisas de produkter som övervägts förutvä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 avPassage.

Kapitel 7 – Test av Rainbow iKey Här presenteras resultaten av utvärderingenav 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 itestnä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.

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

2.1.1 Definition

Den oftast föreslagna definitionen av datasäkerhet kommer från ITSEC (Informa-tion Technology Security Evaluation 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 ellerdra slutsatser om innehållet genom andra tillåtna åtgärder. Integrity handlar omatt förhindra otillåten ändring av information. Man vill inte att någon ska kunnagö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änsterska finnas tillgängliga när de efterfrågas, utan onödiga fördröjningar. Ett sätt attskada en verksamhet är att överlasta till exempel ett nätverk och på så sätt göradet så långsamt att det blir omöjligt att utföra arbete. En risk med för restriktivasäkerhetsmekanismer är att tillgängligheten kan minska eftersom det kan leda tillatt 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.

5

6 Teori

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örstora 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äkerhetgenom att avslöja lösenordet till tredje part, oavsett om detta sker oavsiktligt ellermedvetet. 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 attmanipulera människorna som hanterar datorsystemen istället för att manipuleradatorsystemen 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 valideralö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 skriverin sitt lösenord.

Nästa mänskliga problem är att lösenord måste kunna skrivas in korrekt medtillrä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ändaren ska utföranå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 tredjepart lätt kan gissa eller söka rätt på dem. Födelsedagar och släktingars namn ärexempel 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 hittarätt lösenord. Eftersom användare idag tvingas använda lösenord på en mängdolika platser, till exempel på kontoret och olika webbplatser, ökar risken att deantingen 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, somkanske räcker för att komma åt företagets nätverk, även blir känt av innehavarenav en hemsida på Internet där användaren använder detta lösenord. Om den somfått tillgång till ett lösenord har ont uppsåt skulle denne kunna pröva det kändalö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 attchansen att upptäcka det är liten. Skulle en nyckel komma bort eller stjälas ärdet möjligt att byta låskolvar och om ett passerkort försvinner kan kortläsarnaprogrammeras om, men att ett lösenord kommit på villovägar kanske inte märksfö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örpublik nyckelhantering (PKI) är en uppsättning komponenter som hanterar 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. Dethär avsnittet ger en kort bakgrund till de begrepp inom kryptoteori som behövsfö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 meddelandensker med samma nyckel. Par av avsändare och mottagare delar en hemlig nyckelsom de håller dold för andra än sig själva. Information som krypterats med ennyckel 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 vilkabåda kan användas för att kryptera och dekryptera data. En användare ger sinpublika nyckel till andra användare och behåller själv den privata nyckeln. In-formation som krypterats med den publika nyckeln kan endast dekrypteras medden privata nyckeln och vice versa. [2] RSA-algoritmen [23] är ett exempel på enasymmetrisk krypteringsalgoritm.

Signering

En algoritm för digital signering tar ett meddelande och skapar med hjälp av enprivat nyckel ett nytt meddelande, signaturen, med ett antal speciella egenskaper.Dessa egenskaper innebär att det inte är möjligt att finna två meddelanden somger 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örett givet meddelande utan att känna till den privata nyckeln. Det är vanligt attRSA-algoritmen används som signeringsalgoritm och då skapas signaturen ge-nom att meddelandet krypteras med den privata nyckeln. När mottagaren får detursprungliga 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 mottagarenvara 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

8 Teori

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ändssom 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 meddelandet. Detta medför att om signaturenbaseras 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 hashfunktionsom ska användas i kryptografiska sammanhang har dessutom egenskaperna attdet 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 hashalgoritmsom till skillnad från MD5 skapar längre hashvärden och därmed är starkare motuttö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 associeradeprivata 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 digitala certifikat, vilka är datastrukturer som kopplar sammanpublika nyckelvärden med subjekten. Att denna koppling är korrekt garanterasav en betrodd tredje part som digitalt signerar varje certifikat med sin egen nyc-kel. Denna betrodda part kallas certification authority (CA) och baserar sin garantipå till exempel ett skrivet avtal eller att subjektet presenterar sin privata nyckelför den CA som ska styrka certifikatets giltighet. [11] Vidare förutsätts att en CAendast 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

• subjektets identifieringsinformation som namn och e-postadress

2.3 Standarder för kryptointegrering 9

• giltighetstid

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

Det finns olika uppfattningar och standarder för hur certifikat ska se ut ochvilka 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 somhanterar digitala certifikat.

För att kryptera meddelanden krävs, som skrevs i avsnitt 2.2.1, tillgång tillmottagarens publika nyckel vilket innebär att avsändaren behöver mottagarenscertifikat. Detsamma gäller för att kunna verifiera signerade meddelanden somskickats från den personen. Att ha tillgång till en användares certifikat innebäringen minskad säkerhet för användaren eftersom certifikatet endast innehållerpublik 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 bakgrundentill 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 somanvä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 alltmer. För att denna teknik ska kunna användas så effektivt som möjligt krävs attolika implementationer kan fungera tillsammans, oavsett vilken underliggandeteknik som används. Avsikten med PKCS är att tillhandahålla en grund för attlåta olika PKI-implementationer fungera med varandra. [25]

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

10 Teori

2.3.2 Microsoft CryptoAPI – MS CAPI

MS CAPI är ett högnivågränssnitt mellan Windowsapplikationer och en kärnaför kryptografisk funktionalitet, som är grunden för säkerhetsimplementationer iMicrosoft Windows. Gränssnittet ger alla applikationer tillgång till säkerhetsfunk-tioner utan att applikationerna behöver bry sig om kryptoalgoritmer, privata ellerpublika 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 ochdekryptera 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 applikationenbegä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 ävenbestå till exempel av en kryptografisk enhet i form av ett smartkort. I det senarefallet 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åletmed standarden är att smartkort, kortläsare och datorer från olika tillverkare skafungera tillsammans. Med hjälp av denna standard fungerar CSP:er och appli-kationer med standardläsare utan att tvingas skrivas med tanke på till exempelvilken 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öratt applikationen inte fungerar med framtida läsare. Microsoft har implementeratPC/SC-standarden i Windowsoperativsystemen. [18]

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 ochtillhandahåller medel för hantering av de identiteter och relationer som byggerupp 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 lagraspå servrar som kallas domänkontrollanter och används av nätverksapplikationeroch tjänster. Säkerhet integreras i Active Directory genom autentisering vid in-loggning och åtkomstkontroll till objekt i katalogen. Genom en enda inloggningkan administratörer hantera data i katalogen och auktoriserade användare kankomma åt resurser. Active Directory lagrar information om användarkonton ochgrupper tillsammans med åtkomsträttigheter för dessa. Därför får en användaresom 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 medinformation 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 certifikatsom används för inloggning med smartkort och certifikat för till exempel säkere-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 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 andresidentitet genom att bekräfta att denne känner till hemligheten. I Kerberos bestårhemligheten av en symmetrisk kryptografisk nyckel och den ena parten bevisaratt denne innehar hemligheten genom att kryptera ett meddelande, den andre ge-nom att dekryptera det. Kerberos använder Active Directory som kontodatabasvarifrå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 baseraspå utkast 9 av standardförslaget [30] och Microsoft kommer att revidera imple-mentationen när förslaget antagits som standard [14].

12 Teori

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 sekvensenControl-Alt-Delete (eng. secure attention sequence) som används vid inloggningmed 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 radoperationer 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 verifieraden 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 attinloggningsbegäran kommer från innehavaren av den publika nyckeln. Eftersomcertifikatet hämtades från kortet och signaturen gjorts med den privata nyckelnsom 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 digitalasignaturen. [12]

När en användare är bortkopplad från nätverket eller domänkontrollanten äronåbar på grund av nätverksfel, måste användaren ändå kunna logga in på sinarbetsstation för att utföra sina arbetsuppgifter. Med lösenord stöds detta genomatt 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 ochger en överblick över de moment som jag valt att dela upp projektet i. De centralamomenten 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 momentbestår av.

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

2. BehovsanalysGrunden 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 systemensamt teknisk personal, se avsnitt 3.2. Jag har även läst företagets policy somberö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 somfinns tillgängliga på företaget, för att på så vis förstå problematiken bättre.

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

13

14 Metod

4. ProduktanalysJag gjorde en grov uppdelning av de produkter som jag fann intressanta attundersö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 medegenskaperna som togs fram under behovsanalysen. Se avsnitt 3.3 för attvidare se hur urvalet gick till.

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

6. UtvärderingAvslutningsvis sammanställdes de lärdomar jag dragit under projektet ochresultaten 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 olikaanvändarna har. Målet var att få veta vilka problem personalen ser med dagenssystem, vilka specifika behov de har i sin nätverksmiljö samt vad de förväntarsig av ett framtida system. Jag valde att utföra intervjuerna i en fri form där deintervjuade 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 jagfö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 jagville få fram var åsiktsbetonad art och inte direkt mätbar, i annat fall kunde enenkä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 frekventoch 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 representeraren 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 ävenatt 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 ettsä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å systemethar ä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 ochkraven. En stor källa var Internet, genom produktrecensioner och distributörershemsidor. Dessutom fick jag möjlighet att besöka mässan Infosecurity i Stockholmseptember 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 gjordemig 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 ochså 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 uppfyllakraven 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 urvalav produkterna. Istället för att jämföra varje enskild produkt med behoven kundejag 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 kategoriför att inte missa någon produkts speciella funktioner.

Efter en första grov utrensning gjorde jag en mer noggrann undersökning avkvarvarande 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ättkunna 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 AuthenticationScorecard [22], dock med viss anpassning för att passa mitt projekt bättre. Blandannat 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 punktersom jag valt att behålla och använt som stöd för utvärderingen. Det visade sig attmå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 engrund 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 produkterjä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 dennametod skulle tillföra något större värde för mitt projekt och har därför valt att inteanvända den metoden.

16 Metod

Tabell 3.1. Stödpunkter för produkturval

Lämplighetför användare

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

Flyttbarhet Hur mobil är lösningen, d v skrävs speciell programvara ochhå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ämplighetför företaget

Relativ säkerhet Är autentiseringen stark nog ochimplementationen säker nog?

Kompatibilitet Fungerar produkten med systemsom finns idag?

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

Framtida möjligheter Vilka framtida möjligheter gerprodukten? 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 avhur 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 ibilagorna A, B samt C. Jag har även valt denna uppdelning för att göra det ävenlä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å realistiskafö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öratt 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 Directoryi testnätverket. Dessutom konfigurerades den som CA för att utfärda och hanteratestcertifikat. Se vidare bilaga A för en beskrivning av hur servern konfigurerades.

3.4 Testarbete 17

Klientdatorernas operativsystem var Microsoft Windows 2000 Professional SP4eftersom det finns på företagets arbetsstationer idag. Klienterna installerades ut-an några särskilda inställningar och utöver operativsystemet installerades ävenMicrosofts 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örinte 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ändningenupplevs som mycket snabbare när det sker med en mer kraftfull server och mo-dernare arbetsstationer. Alla datorerna var utrustade med Pentium III-processoroch serverns klockfrekvens var 730 MHz till skillnad från klientdatorernas nå-got blygsammare 550 MHz. Servern och den ena klientdatorn var utrustad med256 megabyte arbetsminne och den andra klientdatorn hade endast 128 megabyteminne.

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öratt 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 enplan för vilka alternativ som skulle väljas under installationen samt vilka anpass-ningar som behövde genomföras på klientdatorerna och servern. Installationernaanpassades för att på bästa möjliga sätt medge produkterna att uppfylla de kravsom ställts på dem. När en produkt var installerad och konfigurerad använde jagmig av den under en längre tidsperiod i testnätverket för att bekanta mig med densamt 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örade uppgifter som den enligt kraven ska klara av.

Efter att ha utvärderat hur väl en produkt uppfyllde grundkraven inriktadestesterna mot den funktionalitet som produkten har utöver grundkraven. Kom-pletterande konfigurering och anpassning av produkten och servern gjordes i defall 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 ocheventuella 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 komponentsom kanske behövde installeras separat men redan installerats för en tidigare pro-dukt.

18 Metod

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 informationpresenteras 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 personalmed ansvar för nätverk och säkerhet. Jag har valt att tilldela varje egenskap enkategori och en prioritet för att underlätta arbetet med att, utifrån dessa, väljaprodukter. De benämningar jag använt är endast korta beskrivande namn för attsä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örfarandeti avsnitt 4.3.

4.1.1 Kategorier

Kategoriseringen är inte helt entydig då vissa av kraven kan placeras i fler än enkategori. 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 handlarom 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. Dessaegenskaper avser att underlätta arbetet för användarna och berör inte säkerhetendirekt, även om ett krångligt system indirekt kan bli mer osäkert då användarnalä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

19

20 Behov

Tabell 4.1. Översikt över önskade egenskaperBenämning Kategori PrioritetNågot man har eller är Säkerhet HögEj fast hemlighet Säkerhet HögNågot man vet Säkerhet HögHemlighet svår att komma åt Säkerhet HögNågot man måste bära med sig Säkerhet MellanBorttagande låser arbetsstation Säkerhet MellanFlera inloggningar Användarvänlighet HögFlera behörigheter Användarvänlighet HögInget extra att bära på Användarvänlighet MellanVäxla identitet Användarvänlighet MellanSnabb inloggning Användarvänlighet MellanSingle sign-on Användarvänlighet MellanLokala konton Användarvänlighet MellanLång inloggning Användarvänlighet MellanBesöka arbetsstation Användarvänlighet MellanGemensam profil Användarvänlighet LågInloggning utan nätverk Användarvänlighet LågInkoppling av extern utrustning Användarvänlighet LågKompatibelt med Active Directory Övrigt HögKompatibelt med CCM Övrigt HögOperativsystem Övrigt HögSupport Övrigt HögIngen extra hårdvara Övrigt MellanPris Ö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ögDessa egenskaper är absoluta krav på det efterfrågade systemet. Produktersom inte kan uppfylla dessa krav är inte användbara för företaget.

• MellanEgenskaper 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ågDessa 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 övrigtanses vara likvärdiga.

4.2 Beskrivning

I detta avsnitt ges en mer ingående beskrivning av de krav och egenskaper somnä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ånde inneboende problemen hos enbart lösenordsbaserade system. Genom att införaen hårdvaruenhet (”något man har”, till exempel ett smartkort eller liknande) sommåste användas vid autentisering säkerställs det att det snabbt märks om någonobehörig har kommit över medel för autentisering. Alternativt kan identifikationgenom 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ärksdå 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 projektetgenomförs.

Ej fast hemlighet:

En hemlig parameter som lagrats på en hårdvaruenhet måste kunna bytas utanatt byta enhet. I fallet att något som lagrats på ett smartkort används direkt somlö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 privatanyckel på enheten i händelse av en lösning baserad på asymmetriskt krypto ellerdigitala 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 enhårdvaruenhet eller att kopiera en hemlig parameter. Därför behöver systemet

22 Behov

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

Hög prioritet motiveras med att ett system baserat enbart på hårdvaruenheterskulle kunna ge en lägre säkerhetsnivå än enbart lösenord, eftersom enheterna gåratt 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ättatt utvinna hemliga parametrar ur denna. Om lagrade lösenord eller en hemlignyckel blir känd kan attackeraren utnyttja detta för att komma åt resurser och idet senare fallet även utge sig för att vara ägaren av kortet. Enheten måste varatillräckligt skyddad mot hårdvaruattacker så att det inte är värt mödan för enobehö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 hemligparameter 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 honlä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 enheternalä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ämdtid 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ämnarden. 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 somredan gjorts på annan dator.

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 administratörs-rättigheter. Vid olika tillfällen behöver användaren logga in med olika roller föratt lösa de olika uppgifter som åligger honom. Systemet måste alltså tillåta att enindivid 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ördet 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 endaenhet. Det är även önskvärt att samma hårdvaruenhet ska kunna användas bådeför lokal inloggning och fjärrinloggning.

Mellanprioritet motiveras med att detta skulle underlätta arbetet för mångaanvä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 annan behörighet änden för tillfället inloggade användaridentiteten medger. För att inte vara tvungenatt avsluta pågående session bör detta kunna utföras utan att användaren måstelogga 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 enkeloch 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 ominloggningsförfarandet vore omständigt och långsamt.


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

24 Behov

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ördet måste övervägas noga hur omfattande och på vilket sätt single sign-on skainfö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 inloggadunder lång tid, typiskt flera dygn. Ett nytt system får inte begränsa den tid enanvä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 ochlä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. Dettaska kunna ske utan att den första användaren loggas ut och uppgiften därmedavbryts.


Gemensam profil:

Vissa användare har behov av att ha exakt samma miljö på sin arbetsstation somandra 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.

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

Inkoppling av extern utrustning:

På en avdelning finns behov av att koppla in datorutrustning som inte kommerfrån företaget på företagets nätverk för att utföra tester. Idag sker detta både i detprimä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 inutrustningen 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åstefungera ä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 CommandCCM. 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 medvissa konton.


Operativsystem:

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


26 Behov

Support:

Det är viktigt att företaget som levererar produkten har en bra organisation därdet 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 ochfö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 enprodukt 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örsmartkort, installeras på arbetsstationerna. Detta skulle minska både kostnaderoch administration. Det skulle även vara användbart vid arbete från persondatori 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årdvaruenheteroch kringutrustning är så låg som möjligt.

Låg prioritet motiveras med att det viktigaste är att anskaffa ett så bra systemsom 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ålsom framkommit under behovsanalysen. Detta gäller bland annat funktionalitetsom 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örheller 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 äratt 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.

4.3 Övrig information 27

4.3.2 Uppstartsskydd

Företaget har ett antal bärbara datorer samt handdatorer som av naturliga skälibland befinner sig utanför företaget. Detta medför att de är avsevärt mycket lät-tare att stjäla än de stationära arbetsstationerna och det finns även risk att sådanaenheter tappas bort. Det kan även på mobila enheter finnas känslig information,och därför är det av stor vikt att skydda dem från obehörig läsning. Att bara havanliga inloggningskrav är inte tillräckligt skydd mot en obehörig som har fysisktillgång till en enhet under en längre tid. Det finns många sätt att kringgå de spär-rar som operativsystemet tillhandahåller, attackeraren kan installera ett eget ope-rativsystem utan spärrar eller flytta hårddisken eller minneskortet som innehållerinformationen till en annan enhet. Fysisk tillgång till lagringsmediet möjliggöräven en rad analysmöjligheter på låg nivå. Det är alltså önskvärt att det inte skavara möjligt att starta en mobil enhet eller ens utläsa information från den utanorimligt stor ansträngning för den som inte innehar rätt behörighet. Om en delav lagringsutrymmet avsätts för känslig information som automatiskt krypterasbör detta omfatta alla platser där användare kan spara filer, alternativt måste detvara mycket enkelt för användarna att välja rätt plats. Om känslig information avmisstag sparas utanför den skyddade lagringsarean förloras det skydd ett sådantsystem skulle tillföra. För att inte obehöriga ska kunna komma åt applikationer,delar av operativsystemet eller information som måste finnas okrypterat vore detönskvärt om skyddet låg utanför operativsystemet, till exempel redan i bootsek-torn på en hårddisk eller motsvarande. På så sätt skulle inga delar av innehållet ien stulen dator vara till nytta för obehöriga. Om skyddet skulle implementeras påså sätt att bara de delar av lagringsmediet där användare förväntas lagra känsligafiler krypteras, måste stor försiktighet iakttas så att det inte är möjligt att få framinformationen genom tillfälliga filer eller växlingsfiler som inte lagras i krypteradform.

4.3.3 Fysisk säkerhet

Det bör inte förutsättas att den fysiska säkerheten i företagets lokaler är total utandet kan vara möjligt för en obehörig person att bereda sig tillträde till kontorsloka-ler. Detta medför att obemannade arbetsstationer och motsvarande ska vara låstaoch att hårdvaruenheter avsedda för autentisering inte lämnas obevakade.

Vidare ska det förutsättas att anställda eller eventuella obehöriga har möjlig-het att koppla in oauktoriserad utrustning i företagets nätverk. Detta medför attprodukter inte får vara känsliga för avlyssning i nätverket, så kallad sniffning. Detnya systemet får alltså inte skicka hemliga parametrar över nätverket i klartext.

4.3.4 Tjänstetillgänglighet

Vid ett framtida beslut om hur en autentiseringslösning baserad på hårdvaruen-heter ska implementeras kommer det att vara viktigt att överväga hotet och ska-dan av undanhållande av tjänster i nätverket (eng. denial of service). Om en hård-

28 Behov

varuenhet förloras finns det risk att användare inte kan komma åt sin arbetssta-tion eller andra resurser som han eller hon behöver i sitt arbete. Detta skulle kunnaöppna för en ny typ av attack, där nyckelpersoners hårdvaruenheter stjäls för atthindra dessa att utföra sitt arbete och därmed skada företaget. Även om enhe-ter förloras genom olyckshändelser skulle detta vara ett problem. Denna möjligaminskning av tjänstetillgängligheten innebär att det måste finnas sätt att omedel-bart medge en anställd att återgå till arbetet, genom att snabbt förse denne meden ersättningsenhet eller genom att på annat sätt bereda den anställde tillgång tillde resurser som krävs.

En möjlighet vore att alltid tillåta inloggning med fasta lösenord vid sidan avautentisering med hårdvaruenheten, men då skulle man igen vara utsatt för desvagheter som lösenord innebär, vilka diskuterades i avsnitt 2.1.2. Möjligen skulleen lösning kunna vara att användaren genom att vända sig till helpdesken kundefå ett lösenord som endast kan användas vid ett enda tillfälle för att låsa uppsin arbetsstation. I så fall krävs rutiner för att otvetydigt säkerställa användarensidentitet för att inte göra sig sårbar för social ingenjörskonst, liknande den metodsom beskrivits i avsnitt 2.1.2.

Kapitel 5

Produkter

I detta kapitel redovisas de produkter som utvärderats och övervägts för närma-re analys. Först delas produkterna in i kategorier efter typ, för att underlätta ettförsta urval. De produktkategorier som inte uppfyller kraven från kapitel 4 av-förs och produkter i kvarvarande kategorier presenteras och analyseras närmare.Även produkter i de kategorier som utesluts i ett tidigt skede presenteras över-siktligt för att öka förståelsen för vad som utmärker de produkter som kommeratt undersökas närmare. För att underlätta för läsaren skrivs namnen på kravenmed kursiv stil när de nämns i texten.

5.1 Kategorier

I det här avsnittet beskrivs de kategorier som jag funnit lämpligt att dela in pro-dukterna i, och vad som utmärker produkterna i varje kategori. Jag ger även enkort beskrivning av de produkter som jag placerat i respektive kategori. Företrä-desvis har indelningen gjorts efter vilken typ av hårdvaruenhet och gränssnittmot arbetsstationer eller nätverksresurser som autentiseringslösningen användersig av. Jag har valt en sådan uppdelning eftersom dessa egenskaper till stor del lig-ger till grund för hur väl lösningen kan uppfylla kraven i kategorin Säkerhet i denkategorisering som gjordes i kapitel 4. Produkter som inte uppfyller de kravenanser jag inte vara lämpliga för företaget och de behöver därför inte undersökasnärmare.

5.1.1 Smartkort

Med smartkort menas hårdvaruenheter i kreditkortsformat som har ett inbäddatdatorchip. Detta chip kan bland annat utföra kryptografiska funktioner och haräven minnesutrymme för att lagra digitala certifikat. De smartkort som finns påmarknaden är, med avseende på funktionalitet, väsentligen identiska. Vissa kortbaseras på Java-teknik och kan lagra och köra appletar skrivna i Java, vilket med-

29

30 Produkter

ger stor flexibilitet. Gränssnittet mellan kort och arbetsstation utgörs av en stan-dardiserad smartkortsläsare (PC/SC-standarden [18]).

RSA Passage med SecurID 5100

SecurID 5100 är ett smartkort från RSA som integreras med mjukvaran Passageför att använda certifikat lagrade på kort i Windowsmiljön. Kortet kan även lag-ra SecurID-frön som tillsammans med särskild mjukvara (så kallade soft tokens)möjliggör att kortet kan användas på liknande sätt som nyckelringsdosan RSASecurID SD600 (se avsnitt 5.1.3). SecurID 5100 baseras på Javacard 2.1.1-teknik,vilket gör det möjligt att använda kortet även till exempel för inpassering eller föratt betala i automater som stöder sådana kort.

SafeGuard Advanced Security

Produktfamiljen SafeGuard Advanced Security från Utimaco Safeware består avmoduler. En av modulerna hanterar autentisering med smartkort.

Cryptocard SC-1

SC-1 är ett smartkort från Cryptocard. Java stöds genom Javacard 2.1.1-standarden.

ActivCard Gold med smartkort

ActivCard Gold är en smartkortlösning som baseras på Javacard 2.1-standarden.Kortet kan lagra användarens fingeravtryck och innehåller funktionalitet för attdirekt på kortet jämföra det lagrade avtrycket med det avtryck användaren har.Om denna funktionalitet ska utnyttjas, krävs en kortläsare som även har fingerav-trycksläsare.

Comex KT 9085

Comex KT 9085 är en avlyssningssäker kortterminal med tangentbord för PIN-kod och avläsare för fingeravtryck. Användaren måste visa sin behörighet att an-vända kortet både genom att ange rätt PIN-kod och genom att placera ett fing-er på avläsaren. Både verifieringen av användarens PIN-kod och jämförelsen avfingeravtrycket med det avtryck som lagrats på kortet sker internt i kortläsaren.Ingen känslig information skickas eller bearbetas alltså utanför läsaren. Termina-len har demonstrerats både med Postens elektroniska ID-kort (eID-kort SIS) ochjavakort från Oberthur.

5.1.2 USB-enheter

Den här kategorin omfattar enheter som typiskt består av ett chip av samma typsom finns på smartkort. Detta innebär att USB-enheten har samma möjligheter attutföra kryptografiska funktioner och att lagra certifikat som smartkort. I enheten

5.1 Kategorier 31

finns en läsare för chippet, och därmed kommer enheten att uppträda som enkortläsare med ett kort i för den arbetsstation som enheten kopplas till. Denna typav enheter stoppas direkt i en ledig USB-port som finns på alla moderna datoreroch har gott stöd av aktuella operativsystem.

RSA Passage med SecurID 6100

Denna produkt är identisk med RSA SecurID 5100, som beskrevs i avsnitt 5.1.1,med undantag för att chip och läsare är integrerade i enheten.

Rainbow iKey

Produktserien iKey från Rainbow Technologies består av olika USB-enheter förautentisering vilka erbjuder olika nivåer av funktionalitet. Enheten iKey 2000 harmöjlighet att lagra certifikat och kan utföra kryptografiska operationer inom en-heten. Rainbow erbjuder även radiokrets för beröringsfria lås som tillval i iKey-serien. Detta gör det möjligt att använda USB-enheten för att låsa upp dörrar.

ActivCard Gold med ActivKey

ActivKey är en bantad variant av det smartkort som erbjuds med ActivCard Gold.Största skillnaden är att USB-enheten har mindre minne för lagring av certifikatsamt inte baseras på Javacard-standarden.

DigiSAFE KeyCrypt

KeyCrypt är en USB-enhet som kan lagra certifikat och utföra kryptografiska funk-tioner. Som tillval finns en inbyggd radioenhet för användning med beröringsfriadörrlås vilket gör att enheten kan användas för inpassering. Som ytterligare tillvalkan enheten utökas till att bli ett USB-minne, det vill säga ett flyttbart lagringsme-dia.

5.1.3 Fristående enheter

Med fristående enheter avses sådana hårdvaruenheter för autentisering som intekopplas in i den arbetsstation som användaren sitter vid. Typiskt används dessaenheter för att generera ett engångslösenord som användaren skriver in för attautentisera sig.

RSA SecurID SD600

SecurID SD600 är en hårdvaruenhet i nyckelringsformat som i en teckenruta vi-sar den engångskod användaren ska ange. Denna kod används tillsammans med

32 Produkter

ett användarnamn och en PIN-kod som användaren anger i anslutning till en-gångskoden när användaren begär tillgång till en skyddad resurs. Användarin-formationen skickas till en RSA ACE-server för godkännande, och om användar-namn, PIN-kod och engångskod godkänns, får användaren tillträde till resursen.Engångskoden genereras i SD600-enheten genom AES-algoritmen, baserat på ensymmetrisk nyckel lagrad i enheten. En ny kod genereras varje minut och dettasker samtidigt i enheten och på ACE-servern, vilket möjliggörs genom RSA:s tids-synkroniseringsteknik. På så sätt vet servern vilken kod som dosan visar vid engiven tidpunkt utan att koden måste skickas över nätverket.

Denna enhet används på företaget för att autentisera användare vid fjärrin-loggning.

RSA SecurID SD520

Enheten SecurID SD520 har samma form som ett kreditkort och är utrustad medett litet tangentbord där användaren skriver in sin PIN-kod. Engångskoder ge-nereras på samma sätt som för SD600 och dessa kombineras med användarensPIN-kod och efter det appliceras en hashfunktion på kombinationen. Koden somvisas i enhetens teckenfönster är hashvärdet av engångskoden och PIN-koden.

Cryptocard KT-1

KT-1 är en nyckelringsenhet som har liknande funktion som RSA SD600. Auten-tisering sker tillsammans med Cryptocards Cryptoadmin-server.

Cryptocard RB-1

RB-1 är en enhet i kreditkortsformat som har ett litet tangentbord. Cryptoadmin-servern skickar en utmaning till användaren som skrivs in på enheten. Enhetenräknar ut ett svar som visas i ett teckenfönster och användaren anger detta svarför att visa sin behörighet.

Xiring

Xiring tillhandahåller fristående läsare för smartkort. Läsaren använder DES-algo-ritmen med en nyckel lagrad på kortet för att beräkna engångskoder. Eftersomdenna produkt inte kopplas till användarens arbetsstation har jag valt att placeraden i denna kategori trots att lösningen innehåller smartkort.

5.1.4 GSM-telefon

Denna kategori innehåller lösningar där användarens mobiltelefon används somautentiseringsenhet. När en användare begär att få tillgång till en resurs får denneskriva in ett användarnamn och ett personligt lösenord. Om detta godkänns skick-as ett engångslösenord till användarens mobiltelefon som ett textmeddelande ochdetta anges för att få tillgång till den begärda resursen.

5.2 Gallring 33

Mideye

För att använda Mideyes autentiseringstjänst installeras en Mideye-server i företa-gets nätverk. Den resurs, till exempel en webbserver, som användaren vill kommaåt vidarebefordrar användarens begäran till Mideye-servern, som i sin tur skickarett lösenord till mobiltelefonen och till webbservern. När användaren anger detmottagna lösenordet till webbservern kan den då avgöra om lösenordet är giltigtoch i så fall tillåta användaren att komma åt resursen. Mideye kommer åt använ-darinformation från Active Directory genom LDAP och stöder Radius-protokolletför autentisering.

RSA Mobile

För att använda RSA Mobile för autentisering mot resurser, installeras en RSAMobile-server i företagets nätverk. Den resurs, till exempel en webbserver, somanvändaren begärt att få tillgång till vidarebefordrar begäran till denna server.Genom samma typ av tidssynkroniseringsteknik som RSA använder i bland an-nat SD600 genererar RSA Mobile-servern och programvaran i webbservern en-gångslösenordet var för sig. På så sätt kan webbservern avgöra att användarenslösenord är korrekt. RSA Mobile hämtar användarinformation via LDAP.

5.2 Gallring

I detta avsnitt görs ett första övergripande urval av produkter för att begränsaarbetet som krävs för en fortsatt djupare analys. Urvalet baseras på de krav ochbehov som återfinns i kapitel 4, främst de med hög prioritet och som placerats iden prioriterade kategorin Säkerhet. De produkter som nämns i detta kapitel haralla vid en första anblick verkat vara intressanta för företaget, vilket innebär attbara produkter som uppfyller de högst prioriterade säkerhetskraven finns med.Eftersom alla kategorier därmed trivialt uppfyller dessa krav, används de kravenhädanefter inte för att välja bort någon kategori.

Kravet på något man har uppfylls genom att alla produkter baseras på en fy-sisk enhet som måste användas vid autentiseringen. Alla produkter kan användasmed certifikat eller annan hemlighet som inte motsvarar ett fast lösenord, vilketmedför att kravet på ej fast hemlighet är uppfyllt. Produkterna kan konfigurerasatt kräva något man vet i samband med autentisering, i form av användarnamnoch lösenord eller ett enkelt PIN. För att garantera hemlighet svår att komma åt, ärprodukterna skyddade mot fysisk manipulation och de flesta uppfyller FIPS 140-1[16], vilket är en amerikansk standard för detta. Att uppfylla någon nivå av denstandarden (högre nivåer innebär starkare skydd mot manipulation) är det vanli-gaste sättet för tillverkare att visa vilket skydd som erbjuds av deras produkter.

34 Produkter

5.2.1 Smartkort

Företagets personal måste alltid bära fotolegitimation synlig när de befinner siginom företagets lokaler. Genom att utforma ett smartkort som ett ID-kort och lå-ta det ersätta det nuvarande ID-kortet skulle autentiseringsenheten bli något manmåste bära med sig. Ett smartkort som har magnetremsa skulle även direkt kunnaanvändas som passerkort i de kortlås som finns på företaget. I framtiden skulleäven kort med Java-teknik också kunna användas till detta. Flera av korten finnsdessutom med radionyckel som tillval. Att använda kortet till inpassering skulleytterligare medverka till att kortet alltid tas med av användarna. För att kommu-nicera med den dator som användaren sitter vid, sätts kortet in i en läsare somi sin tur är ansluten till datorn. Eftersom det finns en koppling mellan kort ochdator kan operativsystemet känna av att kortet sitter i medan användaren är in-loggad och reagera när kortet avlägsnas. De produkter som finns i denna kategorikan konfigureras antingen så att arbetsstationen låses när kortet tas ur läsaren el-ler att användarens session avslutas helt. Borttagande låser arbetsstation gäller alltsåför denna kategori. Kravet på flera inloggningar uppfylls om systemet konfigurerasså att användaren inte loggas ut när kortet tas bort utan arbetsstationen endast lå-ses, dock kan inte användaren ha flera arbetsstationer upplåsta samtidigt utan attha fler än ett kort. Flera behörigheter för användare uppfylls av åtminstone någravarianter av smartkort eftersom korten kan lagra inloggningsuppgifter för flerakonton samt har utrymme för flera digitala certifikat. Därmed är även inget extraatt bära på uppfyllt.

Eftersom denna kategori uppfyller de mest grundläggande kraven och inteuppenbart bryter mot något krav anser jag att denna produktkategori är värd attundersöka närmare.

5.2.2 USB-enheter

Skillnaden mellan en USB-enhet och ett smartkort består endast av storleken ochformen på enheten. Eftersom USB-enheten innehåller den aktiva delen av ett smart-kort, det vill säga datorkretsen, har den samma funktioner och möjligheter sommotsvarande kort. Kopplingen till användarens dator sker genom en USB-portvilket möjliggör låsning när enheten tas bort på samma sätt som med kort ochkortläsare. På grund av enheternas storlek ser jag ingen möjlighet att användadem som legitimation eller liknande. Gränssnittet USB är heller inte lämpat förinpasseringskontroll eftersom det inte finns dörrlås med sådan teknik, dock kanvissa av produkterna utrustas med en radioenhet som, när den hålls upp framförett dörrlås, låser upp dörren. Detta gör ändå att dessa enheter kan vara något manmåste bära med sig.

Det enda som skiljer denna kategori från smartkort är möjligheten att fungerasom ID-kort men detta skulle kunna uppvägas av USB-enheternas mindre storlek.Eftersom de dessutom inte kräver extra hårdvara i form av kortläsare anser jag attdenna kategori är värd att undersökas närmare.

5.3 Närmare analys 35

5.2.3 Fristående enheter

De produkter som är placerade i den här kategorin är svåra att göra tvingande föranvändarna att ta med sig. På grund av nyckelringsstorlek eller att enheten hartangentbord är det inte möjligt att använda enheterna som ID-kort. Av sammaanledningar är de inte heller lämpade som passerkort, ingen av de produkter jagtittat på verkar heller ha möjlighet till radioenhet för dörrlås. Jag kan därför intese att dessa enheter kvalificerar sig som något man måste bära med sig. På grundav att enheterna inte har någon kontakt med en användares arbetsstation medandenne är inloggad garanteras inte heller att borttagande låser arbetsstation. Flera in-loggningar är trivialt uppfyllt eftersom enheterna inte behöver ha kontakt medarbetsstationen när inloggningen väl är utförd. Enheterna hanterar inte flera behö-righeter om inte användare tilldelas flera enheter, vilket skulle strida mot kravetinget extra att bära på.

På grund av att flera av de speciella krav som ställs på lokal inloggning i före-tagets nätverk inte uppfylls i tillräckligt hög grad av produkterna i denna katego-ri anser jag inte att dessa ska undersökas vidare. Eftersom ingen extra hårdvarakrävs när dessa enheter används för autentisering är de bättre anpassade för fjär-råtkomst.

5.2.4 GSM-telefon

Denna lösning är uppenbart inte avsedd för inloggning i nätverk utan mer lämpadför fjärrautentisering mot webbaserade tjänster och liknande. Lösningen lider avsamma brister som kategorin Fristående enheter, det vill säga användare tar intealltid med sig sin mobiltelefon när de lämnar sin arbetsstation och telefonen harheller ingen kontakt med datorn som bryts när telefonen avlägsnas. Ytterligare ettproblem med denna lösning är att endast användare som ofta arbetar från platserutanför företaget försetts med mobiltelefon.

Eftersom flera grundläggande krav inte tillgodoses av en sådan lösning somden här kategorin erbjuder anser jag att dessa produkter inte ska undersökas vi-dare.

5.3 Närmare analys

De produkter som jag, efter ovanstående övervägande, valt att undersöka närma-re är alltså de som beskrivs i avsnitten 5.1.1 och 5.1.2. I detta avsnitt redogör jagnärmare för de olika produkternas egenskaper och hur väl de kan väntas uppfyllaföretagets behov, först det som inte skiljer produkterna åt och därefter ytterligareinformation om respektive produkt. Produkternas specifikationer är hämtade fråntillverkarnas hemsidor, produkternas datablad samt genom kontakt med återför-säljare. Hur väl vissa krav uppfylls är inte möjligt att avgöra enbart genom studieav specifikationer, därför krävs även tester för att undersöka om och hur produk-terna kan anpassas för att uppfylla kraven. Som komplement till behoven använ-

36 Produkter

der jag även punkterna från tabell 3.1 på sidan 16 för att täcka in aspekter somkanske inte kommit fram vid behovsanalysen.

5.3.1 Gemensamt

Vad gäller gränssnitt mot arbetsstationer skiljer sig inte produkterna åt. Smart-kortslösningarna använder sig av PC/SC-standarden som Microsoft stöder, vilketinnebär att det går att använda de flesta kortläsare på marknaden, förutom de lä-sare som medföljer produkterna. För krypterings- och signeringsoperationer följeralla produkter standarderna PKCS #11 samt MS CAPI, vilket gör det möjligt attintegrera produkterna med Windows och Officeapplikationer. För certifikathante-ring stöder alla produkter version 3 av X.509-standarden. Sammantaget ger dettaatt samtliga produkter uppfyller kravet på att fungera med Windows (operativ-system) och att de uppfyller det lika bra. Produkterna stöder även katalogtjäns-ten Active Directory (kravet kompatibelt med Active Directory) och detta täcker till-sammans med det ovanstående in punkten Kompatibilitet från avsnitt 3.3. Kravetkompatibelt med CCM är dock kvar att utvärdera, men detta förläggs till testinstal-lationerna.

Produkterna används i huvudsak på samma sätt, ett kort eller en USB-enhetsätts in en läsare eller en port på datorn och användaren avkrävs sedan ett PIN.Detta förfarande är detsamma som användare är vana vid från vanliga banko-mater och andra liknande maskiner som är en del av vardagen. Det krävs därförinte någon omfattande utbildning av slutanvändare. Punkten Användarvänlig-het talar därför för de kvarvarande produkterna, men inte mer för någon enskildprodukt. De ännu ej behandlade kraven från kapitel 4 som hör till kategorin An-vändarvänlighet går inte att avgöra enbart med utgångspunkt i den tillgängligaproduktinformationen så de måste undersökas under testinstallationer.

Punkten Flyttbarhet skiljer produkterna åt i kategorierna smartkort respektiveUSB-enheter. Kortlösningarna kräver att kortläsare installeras på samtliga datorersom användare ska kunna använda med kort medan företagets samtliga arbets-stationer och bärbara datorer redan är utrustade med USB-portar.

5.3.2 RSA Passage

SecurID-enheterna 5100 och 6100 som används med RSA:s Passage-produkt stö-der kryptoalgoritmerna 3DES och RSA samt SHA-1 för hashning. Enheterna haren kryptografisk hjälpprocessor och kan därmed utföra till exempel krypteringmed asymmetriska nycklar och validering av signaturer. Enligt tillgänglig pro-duktinformation stöder SecurID-enheterna RSA-nycklar av 1024 bitars, såväl som2048 bitars längd. Enheterna är även validerade för FIPS 140-1, nivå 2, vilket inne-bär att de måste uppvisa synliga tecken på manipulation om någon försökt kom-ma åt det inre av enheterna. USB-enheten uppfyller även (som tillval) nivå 3 avstandarden FIPS 140-2 [17] som efterföljer FIPS 140-1, denna nivå innebär att en-heten är konstruerad för att förhindra att hemligheter inom enheten kan kommasåt genom yttre påverkan. [26]


Med Passage kan användaren lagra användarnamn och lösenord för olika ap-plikationer på sin kryptografiska enhet och slipper på så vis komma ihåg flera oli-ka lösenord. Om denna funktion aktiveras kan dessa lösenord fyllas i automatisktså att användaren slipper att skriva in dem för varje resurs denne vill komma åt.Med denna funktion erhålls en variant av single sign-on, vilket är önskvärt enligtkraven. Trots att lösenord lagras på en mycket säker plats i form av en krypto-grafisk enhet, finns det risk att lösenorden komprometteras om de används förlänge. Därför kommer lösenorden att behöva bytas med jämna mellanrum vilketkan medföra nya problem. När ett lösenord byts mot ett nytt måste samtidigt upp-gifterna som lagrats på enheten uppdateras med nytt innehåll. Om inte detta skerkan användare vars enheter inte uppdaterats finna sig utelåsta från resurser ochtvingas vända sig till supportavdelningen. För att inte införa ökad belastning påsupportpersonal och minimera administrationen krävs att användare får utbild-ning i hur enheten ska handhas och hur lösenord byts.

Datorkretsen som finns på smartkortet och i USB-enheten har, förutom hjälp-processorn för kryptooperationer, även en virtuell maskin för Java. Appletar somskrivits enligt Javacardspecifikationen [28] ska kunna köras på alla kort som stö-der denna teknik. Fördelen med enheter som kan köra Javaappletar är att enheter-na kan utökas med ytterligare funktioner som kanske inte ens varit planerade närenheterna inskaffades. Utrymmet för appletar delas med det tillgängliga minnetför lagring av certifikat vilket för båda enheterna är 32 kilobyte stort.

Passage gör det möjligt att använda enheterna 5100 och 6100 på liknande sättsom enheten SD600. Fröet som används för att räkna ut den aktuella engångsko-den lagras på den kryptografiska enheten istället för i en SD600-enhet. Algoritmenutförs i detta fall av mjukvara på användarens dator. Denna möjlighet skulle even-tuellt kunna vara intressant för företaget eftersom denna teknik redan används förfjärråtkomst och då det finns en ACE-server på plats som används tillsammansmed tidssynkroniseringstekniken.

Kortet 5100 finns att få med beröringsfri låskrets för fysisk inpassering menUSB-enheten 6100 brukar inte erbjudas med det. Dock är det enligt RSA:s repre-sentant möjligt att utrusta även 6100 med denna teknik genom att de tar in enannan produkt från hårdvarutillverkaren så länge som denna fungerar på sammasätt tillsammans med mjukvaran Passage.

RSA Passage är en produkt som verkar kunna uppfylla de flesta krav somställts och har goda möjligheter att tillföra ytterligare funktionalitet i framtiden.Att produkten erbjuds både med smartkort och med USB-enhet, vilka har sammafunktionalitet gör den intressant för att kunna jämföra fördelar och nackdelar medkort respektive USB-enhet. Jag kommer därför att installera och testa RSA Passagemed både smartkort och USB-enhet.

5.3.3 SafeGuard Advanced Security

SafeGuard Advanced Security erbjuder autentisering med smartkort genom bas-modulen och erbjuder single sign-on genom en utökningsmodul. Produkten an-vänds med standardiserade smartkort och kan även användas för fjärrautenti-

38 Produkter

sering. [31] Information utöver detta har varit svårt att få fram inom rimlig tid,varför denna produkt inte kommer att utvärderas närmare.

5.3.4 Cryptocard SC-1

Detta kort baseras på Schlumbergers Cryptoflex-kort som stöder bland annat 3DES,RSA samt SHA-1. Utrymmet för certifikat och Javaappletar är 32 kilobyte och Ja-va stöds genom Javacard 2.1.1-standarden. Kortet uppfyller FIPS 140-1, nivå 2 ochkan levereras med radioenhet för inpassering. [5] I övrigt är den tillgängliga in-formationen om denna produkt knapphändig, varför den inte kommer att utvär-deras närmare.

5.3.5 ActivCard

Kortet som används med produkten ActivCard Gold har 64 kilobyte utrymmeför certifikat och Javaappletar. Stödet för Java erhålls genom standarden Javacard2.1 och de kryptoalgoritmer som stöds är DES och RSA med upp till 1024 bitarsnycklar samt DES-MAC. Kortet kan levereras med radioenhet för inpassering. [1]

Alternativt används ActivCard Gold med en USB-enhet som kallas ActivKey.Denna enhet saknar Javastöd och har endast 16 kilobyte minne. Den kan inte hel-ler användas för fysisk inpassering. Visserligen är det positivt att produkten er-bjuds med både smartkort och USB-enhet för den händelse företaget önskar kom-binera dessa lösningar. Dock är det i sådant fall önskvärt att enheterna har så likafunktionalitet som möjligt för att minska administration av enheterna, idealt skul-le båda typer av enheter vara funktionellt helt utbytbara så att det enda som avgörvilken enhet en användare utrustas med är önskad formfaktor. Att enheterna somerbjuds tillsammans med ActivCard Gold har såpass olika prestanda försvårar ensådan lösning eftersom enheterna inte skulle vara direkt utbytbara.

Produkten ActivCard Gold har, enligt uppgift, tidigare utvärderats inom fö-retaget och jag har därför ombetts att inte inkludera denna produkt i den vidareundersökningen.

5.3.6 Comex KT 9085

Denna kortterminal är ett mer avancerat alternativ än de kortläsare som användstillsammans med de övriga produkterna. När en PIN-kod anges till ett smart-kort som är anslutet till en vanlig kortläsare, skickas PIN-koden från datorns tan-gentbord, via datorn och vidare till kortläsaren och slutligen kortet. I mycket sä-kerhetskritiska sammanhang kan detta tänkas vara oacceptabelt och där skulleComex kortterminal kunna vara lösningen. Eftersom PIN-koden anges direkt påterminalen och verifieringen av den sker innan någon information skickas till da-torn, försvåras avlyssning av PIN-koden markant, vilket i värsta fall skulle kunnavara möjligt i fallet med vanliga kortläsare. [3] Dock är det rimligt att anta attdenna lösning skulle vara mer kostsam än mer standardiserade kortläsare. Vis-serligen är kravet på låga kostnader lågprioriterat i denna undersökning men på


grund av produktens relativa komplexitet antar jag att priset för terminalerna ärav en annan storleksordning än för vanliga kortläsare. Därför anser jag att Comexterminal skulle vara mer intressant för ett fåtal speciellt känsliga datorer och inteför varje arbetsstation på företaget.

5.3.7 Rainbow iKey

Det finns tre varianter av USB-enheten iKey. Den enklaste, iKey 1000, utför in-te kryptografiska funktioner inom enheten, vilket innebär att till exempel signe-ring måste utföras av mjukvara på arbetsstationen som enheten kopplas till. Dettamedför att användarens privata nyckel måste överföras från enheten till arbetssta-tionen och det kan innebära ökad risk för att nyckeln avlyssnas. Varianterna 2032och 3000 behöver inte släppa privata nycklar utanför enheten utan har kapacitetatt utföra kryptografiska operationer. Skillnaderna mellan iKey 2032 och 3000 ärsmå, den största är att 3000 har två PIN-nivåer, där den ena ger administratörs-behörighet för USB-enheten. Detta innebär att om enheten blir låst på grund avatt fel PIN anges för många gånger, så är det möjligt att återställa enheten medadministratörs-PIN. Om en iKey 2032 blir låst måste den initialiseras på nytt vil-ket innebär att alla lagrade certifikat och nycklar förloras. Dessutom stöder iKey3000 standarden PKCS #15, vilket iKey 2032 inte gör. I produktinformation frånRainbow beskrivs iKey 2000 som en modell med 8 kilobyte lagringsutrymme samtiKey 2032 med 32 kilobyte utrymme, den mindre varianten har dock utgått så ommodell 2000 omnämns i företagets information utgår jag från att de hädanefteravser modell 2032. [20]

Enheterna i iKey-serien stöder ett antal algoritmer för kryptering och signe-ring, däribland 3DES, RSA, SHA-1 samt MD5. Asymmetriska kryptooperationeroch signering genom RSA-algoritmen stöds med 1024 eller 2048 bitars nyckel-längder. iKey 2032 finns i två varianter, där den ena uppfyller FIPS 140-1, nivå2. 2032-enheten är baserad på teknik från Datakey, och har samma funktionali-tet som Datakeys smartkort. Detta innebär att det är möjligt att använda dessakort tillsammans med kortläsare för att erhålla en identisk lösning som iKey base-rad på kort om det skulle vara önskvärt. Kryptoprocessorn i dessa enheter är enPhilips P8WE5032 med Datakey Cryptographic Card Operating System. [6]

Förutom certifikathantering och kryptofunktioner erbjuder inte iKey någrauppenbara ytterligare användningsområden utöver användarautentisering. En-hetens formfaktor medger inte att den används som fotolegitimation och USB-gränssnittet är inte vanligt i andra tillämpningar än persondatorer. Som nämndesovan finns dock möjligheten att utrusta iKey 2032 med ett extra chip som gördet möjligt att använda enheten som nyckel genom att hålla upp den framför ensensor i anslutning till dörrar. Detta kom fram i samtal med Rainbows engelske re-presentant och är inget som nämns i produktinformation någonstans och erbjudsinte som standardtillval utan ordnas bara vid större beställningar.

Till skillnad från bland andra SecurID-enheterna har inte iKey stöd för Javatek-nik vilket innebär att mängden av framtida möjligheter är mer begränsad. Trots attframtida Javabaserade utökningar inte är planerade kan det tänkas att företaget

40 Produkter

prioriterar en mer flexibel lösning. Att enheten inte baseras på Java kan innebä-ra ökad prestanda i form av kortare svarstider från enheten vilket skulle upple-vas som positivt av användarna. Att denna enhet på papperet är väldigt lik RSASecurID-enheterna fast baseras på annan teknik gör det intressant att ställa dessaprodukter mot varandra och göra en direkt jämförelse av enheternas prestanda.Därför kommer jag att installera och testa denna produkt.

5.3.8 DigiSAFE KeyCrypt

Denna enhet baseras på den kryptografiska hjälpprocessorn Cryptoflex eGate frånSchlumberger som kan utföra RSA-operationer med 1024 och 2048 bitars nyckel-längder samt även stöder 3DES, SHA-1 och MD5. KeyCrypt är även certifierad förFIPS 140-1, nivå 2. [8]

KeyCrypt har som tillval radioenhet för inpassering och även minneskort påupp till 256 megabyte så att enheten blir en flyttbar lagringsenhet. Det senare möj-liggör vissa tillämpningar som kan vara användbara. I detta utförande kan driv-rutiner för enheten och programvara, till exempel VPN-klient och e-postklient,lagras på själva enheten vilket skulle göra det mycket enkelt att fjärransluta säkertfrån vilken plats som helst. Storleken på lagringsutrymmet, om enheten utrustassom ett flyttbart minne ska inte förväxlas med det utrymme som finns tillgängligtför lagring av certifikat vilket är 32 kilobyte för denna enhet. [8]

Det kan finnas fördelar med att ge användarna en flyttbar lagringsenhet utanatt behöva belasta dem med flera enheter att bära på men jag tycker dock inte attdetta ska göras utan eftertanke. Det kan finnas en pedagogisk vinst med att skiljapå koncepten autentiseringsenhet och lagringsmedia för att inskärpa allvaret medatt hantera en kryptografisk enhet. För att inte blanda dessa koncept i utvärdering-en, utan testa enheter med enbart säkerhetsrelaterad funktionalitet, kommer jaginte att undersöka denna produkt närmare.

5.4 Resultat

Av de produkter som beskrivits översiktligt har ett stort antal valts bort på grundav att de inte ansetts uppfylla företagets behov. Några av dem kan dock eventuelltvara intressanta att undersöka närmare i framtiden inför andra tillämpningar. Avde övriga produkterna, som beskrivits mer ingående, är de flesta mycket lika av-seende funktioner och specifikationer. Detta har förstås gjort det svårare att skiljadem åt utan att testa samtliga, vilket tidsplanen för detta projekt inte medger. Tvålösningar har valts ut för vidare testning med motivering att de till synes uppfyllerde krav och behov som tagits fram (se kapitel 4) samt att kontakten med svenskadistributörer gått smidigt och testprodukter därför gått snabbt att få fram.

RSA Passage har valts eftersom den produkten har möjlighet att tillföra storamervärden utöver de behov som företaget har idag. Dessutom erbjuds som stan-dard en lösning med smartkort (SecurID 5100) eller USB-enheter (SecurID 6100),

5.4 Resultat 41

vilket gör det möjligt att jämföra egenskaperna hos dessa två typer av kryptogra-fiska enher, vad gäller användarvänlighet och prestanda.

Rainbow iKey har valts på grund av att denna lösning, enligt specifikationer-na, verkar ha möjlighet att uppfylla företagets behov lika väl som RSA Passagemen till viss del baseras på annan teknik. Detta ger möjlighet att undersöka omJavatekniken i Passage påverkar prestandan och om frånvaron av Java i iKey med-för några begränsningar. Skillnader i medföljande mjukvara är förstås även intres-sant att undersöka eftersom detta är en stor del av lösningen, hårdvaruenheternaär ofta utbytbara mot likvärdiga enheter om det behövs.

42 Produkter

Kapitel 6

Test av RSA Passage

I detta kapitel beskrivs produkten Passage från RSA Security. Först ges en allmänbeskrivning av hur produkten används av slutanvändare samt administration avprodukten och närliggande tjänster. Därefter redovisas hur produkten uppfyllerde krav som ställts upp och sist ges en kort genomgång av den funktionalitetutöver kraven som produkten erbjuder.

6.1 Allmänt

RSA Passage kan användas med kryptografiska hårdvaruenheter i form av USB-nycklar eller smartkort, vilka erbjuder samma funktionalitet. Passage är namnetpå programvaran för hantering av enheterna och integrering av dessa i Windowsinloggningsmekanismer. I det här avsnittet bekrivs hur produkten ser ut för an-vändare samt hur administrationen av den går till.

6.1.1 Administration

Avsikten med detta avsnitt är att ge en överblick av administrationen av Passage.Se bilaga B för detaljer om hur installationen av produkten gick till och hur denkonfigurerades.

Grundinställningar för Passage kan göras redan vid installationen av program-varan. Därefter hanteras inställningarna från programvaran Passage Control Cen-ter, se figur 6.1. SecurID-enheterna (smartkortet 5100 och USB-enheten 6100) somanvänds med Passage är klara att användas vid leverans och har en förinställdPIN-kod. Passage kan konfigureras att kräva att denna PIN-kod byts första gång-en en ny enhet används, vilket är ett bra sätt att garantera att den fabriksinställdakoden inte finns kvar på några enheter. Framtida byten av PIN-koder kan använ-darna själva sköta från Control Center. För att underlätta för användarna tillåterPassage i grundkonfigurationen att PIN-koden lagras i Windowsregistret efter attden angivits första gången, för att användaren inte ska tvingas ange den varje

43

44 Test av RSA Passage

Figur 6.1. Control Center för Passage. Källa: Egen konstruktion

gång en skyddad operation ska utföras, och sparas där i en valbar tid. De tidersom visas i figur 6.1 innebär att användarens kod sparas i upp till 60 minuter medbegränsningen att om ingen operation som kräver PIN-kod utförts på 10 minuterså raderas koden från registret och användare kommer att avkrävas sin PIN-kodpå nytt. Det är möjligt att anpassa formatet för PIN-koderna för att till exempelkräva längre koder än vad som ursprungligen krävs, eller för att ställa in vilkatyper av tecken som kan användas. Detta görs till exempel genom att sätta vär-den på en uppsättning nycklar i Windowsregistret, vilkas namn och format finnsbeskrivna i administratörshandledningen för Passage [27].

För att hantera de certifikat som lagrats på enheterna används Certificate Ma-nagement Tool, vilket visas i figur 6.2. I denna vy visas information om de certi-fikat som finns på enheten. Enheterna kan lagra upp till tre certifikat men det ärendast ett av dem, som markerats som standardcertifikatet, som kan användas förWindowsinloggning. Därför finns möjligheten att bestämma vilket av certifikatensom ska vara förvalt. Begränsningen att endast ett certifikat på en kryptografiskenhet kan användas för inloggning beror på det sätt som Windows 2000 hante-rar inloggning med sådana enheter [12]. Det går även att registrera certifikatenpå datorn, vilket krävs för att kunna använda dem för kryptografiska operationeri applikationer på arbetsstationen. Det certifikat som användaren loggat in medregistreras automatiskt, och det går att konfigurera Passage att alltid registrera al-la certifikat på en enhet vid inloggning. Om detta inte ställts in måste de övriga

6.1 Allmänt 45

Figur 6.2. Certifikatlistan i Passage. Källa: Egen konstruktion

certifikaten registreras manuellt genom certifikathanteraren innan de kan använ-das för kryptografiska operationer. Val för att radera certifikat från enheten finnsäven och det går att se vilka certifikat som är registrerade på arbetsstationen. Nyinformation för kryptografiska operationer importeras från filer som är i PKCS#12-format, vilka bland annat kan innehålla certifikat och privata nycklar.

När Passagekomponenten för kryptografiska tjänster installerats på en arbets-staion får användarna tillgång till certifikathanteraren och kan då registrera sinacertifikat. Dock får de även möjligheten att radera certifikat vilket inte är önskvärt.Genom att ställa in Passage till att automatiskt registrera certifikat åt användar-na, minskar behovet för användarna att använda certifikathanteraren och därmedminskar även risken att någon olyckligt raderar viktiga certifikat.

Som beskrivits ovan kan certifikat och nycklar importeras till enheten men en-heten kan även själv generera nycklar, vilket ur säkerhetssynpunkt är det bästasättet att hantera användare med kryptografiska enheter. Eftersom nycklarna ge-nereras internt i enheten behöver den privata nyckeln aldrig lagras eller hanteraspå annat sätt utanför enheten och risken att den skulle kunna fångas upp någon-stans minimeras. Utfärdandet av certifikat kan till exempel göras från särskildastationer via webbgränssnittet till Windows CA-tjänst, se figur 6.3. När en admi-nistratör enrollerar en användare (det vill säga tilldelar användaren ett certifikatmed tillhörande nycklar) väljer denne den CSP (se avsnitt 2.3.2) som motsvararden kryptografiska enheten. För Passage ska Passage Enhanced Cryptographic Pro-vider väljas. Nyckelgenereringen sker då i SecurID-enheten som sedan skickar utden publika nyckeln samt en digital signatur, vilket CA:n använder för att ska-pa motsvarande digitala certifikat. Observera att den privata nyckeln i nyckelparsom genererats i en SecurID-enhet inte tillåts att exporteras från enheten och attdet därför inte är möjligt att använda certifikatet för att signera eller kryptera med-delanden om inte motsvarande enhet är ansluten till datorn.

Det är även möjligt att använda Passage och de kryptografiska enheterna förinloggning med textbaserad användarinformation till skillnad från certifikatin-loggning. För att göra detta väljs inställningen Passage Logon istället för MicrosoftLogon i Control Center, vilket ersätter Windows inloggningsskärm med en ny GI-


Figur 6.3. Utfärdande av certifikat att lagras på Passage-enhet. Källa: Egen konstruktion

NA. Denna GINA läser kontoinformationen från enheten som används för inlogg-ningen och använder denna information för att autentisera användaren mot do-mänen. Kontoinformationen för upp till tre konton hanteras i den del av ControlCenter som visas i figur 6.4. För varje konto ska användarnamn, domännamn ochlösenord anges och den informationen lagras säkert i den kryptografiska enheten.

För att underlätta administrationen av en större installation av Passage, med-följer policymallar för bland annat Windows 2000 och Windows XP. Alla inställ-ningar som kan göras från Passage Control Center kan även manipuleras via do-mänpolicyn vilket ger möjligheten att centralt ändra inställningar för alla klient-datorer i domänen.

6.1.2 Användning

Vid inloggning till en arbetsstation med Windows 2000 möts användaren av envälkomstskärm med uppmaningen att trycka tangentkombinationen Control-Alt-Delete. Detta är en så kallad secure attention sequence och eftersom den alltid fångasupp av operativsystemet vet användaren att det lösenord denne skriver in verk-ligen går till inloggningsprocessen och inte fångas upp av något program somimiterar Windows GINA för att stjäla lösenord. När Passage samt drivrutiner försmartkortläsare eller USB-enheter installerats på en arbetsstation räcker det medatt ansluta SecurID-enheten till en arbetsstation istället för att trycka Control-Alt-Delete. Detta indikeras i välkomstskärmen i Windows GINA som en liten bild

6.1 Allmänt 47

Figur 6.4. Hantering av konton i Passage. Källa: Egen konstruktion

av ett smartkort, se figur 7.4 på sidan 58. När en enhet för inloggning anslutitsuppmanas användaren att skriva in sin PIN-kod för enheten, se figur 7.5 på si-dan 59. Denna kod används endast för autentisering mot SecurID-enheten ochmotsvarar alltså inte det lösenord som användaren normalt använder eftersomdomänautentiseringen sker med certifikat. När användaren autentiserats sker in-loggningen som vanligt och användaren märker inte mer av skillnaden mot detvanliga förfarandet.

Det är, som beskrivits i avsnitt 6.1.1 ovan, även möjligt att lagra informationför domäninloggning på SecurID-enheter för att logga in med smartkort utan attanvända certifikat. Detta kallas hädanefter Passage-inloggning. För användarnaskiljer sig inte förfarandet vid denna typ av inloggning nämnvärt jämfört medcertifikatinloggning, det enda som syns är att Windows GINA ersatts av en GI-NA med något annorlunda utseende. Inloggningsförfarandet är dock detsamma,istället för att trycka Control-Alt-Delete ansluter användaren sin SecurID-enhetoch skriver därefter in sin PIN-kod för enheten. När enheten verifierat att kodenär korrekt används kontoinformationen på enheten för inloggning i domänen, ochom enheten innehåller flera konton presenteras dessa för användaren som väljervilket av kontona som ska användas. Samma enhet kan lagra både konton förPassage-inloggning och inloggningscertifikat, det är konfigurationen av den ak-tuella arbetsstationen som avgör vilken metod som används.

Med både certifikatinloggning och Passage-inloggning kan användaren låsa


arbetsstationen och stänga av den på samma sätt som vanligt. En skillnad är attarbetsstationen även låses omedelbart när enheten tas bort från kortläsaren ellerUSB-porten som den anslutits till (om inloggningspolicyn konfigurerats för det-ta; se bilaga B). Det är möjligt att även tillåta inloggning med vanliga lösenordparallellt med certifikatinloggning eller Passage-inloggning.

För att underlätta användarnas hantering av lösenord för applikationer ochwebbtjänster kan Passage konfigureras för att lagra sådana lösenord på SecurID-enheter. I Control Center aktiveras igenkänning av lösenordsfält, se figur 6.5, ochdärefter kommer Passage att detektera frågor om lösenord. När en begäran om lö-senord upptäcks frågas användaren om denne vill att Passage ska lära sig lösenor-det och om användaren så önskar anger denne användarnamnet och lösenordetför den aktuella tjänsten och de uppgifterna lagras då på enheten. När Passageidentifierar en begäran om lösenord från samma formulär i samma applikationeller från samma webbtjänst, fylls de uppgifter som användaren lagrat på enheteni automatiskt. Upp till 15 lösenord kan lagras på en enhet, dock är en begränsningmed hanteringen av lösenord för webbsidor att Passage associerar webbtjänstermed enbart domännamnet, vilket innebär att det endast är möjligt att lagra ettlösenord per webbserver.

Figur 6.5. Hantering av lösenord i Passage. Källa: Egen konstruktion

Om användarens certifikat är av typen Smartcard User kan det även användasför säker e-post till skillnad från certifikat av typen Smartcard Logon som endastkan användas för inloggning. När e-postklienten, i det här fallet Outlook, konfi-

6.2 Kravuppfyllnad 49

gurerats för att hantera säker e-post med certifikat som lagrats på en kryptogra-fisk enhet fungerar det utmärkt att skicka och ta emot signerad och krypterade-post. När e-post ska signeras eller krypterad e-post ska läsas krävs att använda-ren anger sin PIN-kod för den kryptografiska enheten eftersom det är operationersom använder den privata nyckeln. I övrigt märker användaren inte att krypto-nycklarna ligger på ett smartkort eller en USB-enhet och inte lokalt på arbetssta-tionen.

Jag har även testat att använda så kallade mjukvaruenheter (eng. software to-kens) lagrade på smartkort för inloggning i Windows 2000. Användaren uppma-nas att trycka Control-Alt-Delete vid den vanliga välkomstskärmen, för att inledainloggningen och, efter att denna tangentkombination tryckts visas en ny inlogg-ningsskärm som installerats tillsammans med ACE-agenten. Här ska använda-ren i en rullista välja att autentisera sig med en mjukvaruenhet som lagrats påett smartkort samt ange sitt användarnamn och den PIN-kod som krävs för denmjukvaruenhet som används. När detta utförts vidarebefordrar ACE-agenten an-vändaruppgifterna och den aktuella engångskoden till en ACE-server som kon-trollerar dem och godkänner autentiseringen. Därefter medger ACE-agenten till-gång till Windows egen GINA där användaren får logga in med sitt användar-namn och lösenord, dock är det endast möjligt att logga in med det användar-namn som associeras med den mjukvaruenhet vilken användes för autentiseringmed ACE-agenten. Fördelen med denna typ av autentisering är att företagets ex-isterande ACE-server kan användas, dock blir inloggningsförfarandet invecklateftersom användarna måste komma ihåg tre lösenord för att logga in. Först måstePIN-koden till smartkortet anges för att ge tillgång till den mjukvaruenhet somlagrats på det, därefter anges PIN-koden för den mjukvaruenheten och sist krävslösenordet till Windowsinloggningen.

6.2 Kravuppfyllnad

I detta avsnitt undersöks hur väl produkten RSA Passage uppfyller de krav somställts upp, se tabell 4.1 på sidan 20.

6.2.1 Säkerhet

Som beskrivits i kapitel 5 uppfyller Passage kraven i kategorin Säkerhet i grundut-förandet. Smartkortet går att använda både som fotolegitimation och för att låsaupp dörrar med läsare för magnetkort eftersom kortet har en magnetremsa. Bådekortet och USB-enheten kan dessutom, enligt uppgift från leverantören, utrustasmed radioenhet för inpassering utan att behöva ansluta enheten till en läsare.



När en användare är inloggad på en arbetsstation och tar med sig enheten kandenne använda enheten för att logga in på andra arbetsstationer, kravet på flerainloggningar är alltså uppfyllt även om endast den dator där enheten är anslutenför tillfället kan vara upplåst. För inloggning med certifikat stöder Windows 2000endast ett certifikat per hårdvaruenhet, dock erbjuder Passage även möjlighetenatt lagra användarnamn, lösenord och domännamn för upp till tre konton på en-heten. Det skulle alltså till exempel vara möjligt att låta en användare autentiserasig mot sitt primära konto med certifikat och lagra lösenord för eventuella övrigabehörigheter på kortet. På detta sätt uppfylls kravet flera behörigheter såväl sominget extra att bära på. Dock är det inte möjligt att konfigurera en dator att tillåtainloggning med både certifikat och de lösenord som lagrats på kortet, dessa behö-righeter måste alltså användas på olika arbetsstationer. Att växla identitet fungerarpå samma sätt som vanligt med hjälp av Windows sekundära inloggning vilketsker genom kommandot runas och medger att applikationer kan köras med and-ra rättigheter än den inloggade användaren har. Detta kan även stängas av genomatt Runas-tjänsten avaktiveras.

Det uppstår en mycket lång fördröjning vid inloggning med certifikat efteratt en hårdvaruenhet anslutits till datorn och användaren angivit sin PIN-kod.Jämfört med den tid som inloggning med lösenord behöver, tar det ytterligareca 60 sekunder vid certifikatinloggning innan användaren kan använda datorn.Detta medför att kravet på snabb inloggning inte uppfylls, den extra tid som au-tentiseringen tar upplevs som mycket lång av användare som försöker logga inmed smartkort och USB-enheter. Enligt min kontaktperson och teknisk personalpå RSA är detta ett feltillstånd och inloggningen borde gå mycket snabbare meddenna produkt. Enligt uppgift är utvecklingsavdelningen engagerad i felsökningoch en uppdatering som åtgärdar problemet är utlovad. Om fördröjningen åtgär-das kan kravet på snabb inloggning komma att uppfyllas av kommande versionerav Passage.

Passage erbjuder möjligheten att lagra lösenord för applikationer och webbsi-dor på hårdvaruenheterna, vilket ger en enkel form av single sign-on. Inloggningtill lokala konton stöds av Passage genom att textbaserad kontoinformation kan lag-ras på smartkort eller USB-enheter. Som nämnts ovan kan dock en enskild datorinte konfigureras att både acceptera inloggning med sådana uppgifter och certifi-kat, varför lokal inloggning med hårdvaruenheter endast kan ske på arbetsstatio-ner där certifikatinloggning inte stöds. Det finns inget som hindrar lång inloggning,det fungerar precis som vanligt. Det är möjligt att koppla flera certifikat till sammakonto för inloggning, därför går det att besöka arbetsstation och att ha en gemensamprofil på arbetsstationer är då trivialt uppfyllt eftersom flera användare kan an-vända samma konto. Windows sparar information om utförda inloggningar ochmedger inloggning utan nätverk även för certifikatbaserad inloggning på motsva-rande sätt som för inloggning med lösenord. Inkoppling av extern utrustning stödsinte på något enkelt sätt eftersom mjukvaran Passage i så fall måste installeras ominloggning på utrustningen ska ske med hårdvaruenheter.

6.3 Övriga bedömningsgrunder 51

6.2.3 Övrigt

De flesta kraven i kategorin Övrigt är trivialt uppfyllda i och med att produk-ten gått att installera och använda både i en miljö som liknar företagets ordinarienätverk och direkt i detsamma. Kompatibelt med Active Directory uppfylls eftersomdet är just Active Directory som hanterar användarkonton i båda domänerna. Ef-tersom det är möjligt att tillåta vissa konton att använda lösenord för inloggningär detta kompatibelt med CCM som behöver denna möjlighet för att utföra uppgif-ter på klientdatorerna. De operativsystem som använts i testerna är identiska medföretagets servrar och klienter och eftersom tester även genomförts i företagetsskarpa nätverk, anser jag att det inte finns några tvivel om att produkten kan fun-gera tillsammans med de system som finns idag. Min kontaktperson på RSA harsvarat snabbt och väl på mina frågor och varit allmänt tillmötesgående och RSAverkar allmänt ha ett gott anseende i branschen. Detta borde kunna borga för gottuppfyllande av kravet på support för dessa produkter. Dock tog det flera veckor attfå aktiv hjälp med de fördröjningar som beskrivits i avsnitt 6.2.2, varför intrycketinte är odelat positiv.

Lösningen med smartkortet 5100 uppfyller inte kravet på ingen extra hårdvaraeftersom varje arbetsstation måste utrustas med kortläsare. Det kravet kan ändåuppfyllas av Passage om USB-enheten 6100 väljs istället, i så fall utnyttjas datorer-nas befintliga USB-portar. Pris för produkten varierar med beställningens omfatt-ning, enligt uppgift är storleksordningen $70–$80 per licens med de erbjudandensom finns i skrivande stund. Detta inkluderar smartkort och supportkostnader.För kortläsare tillkommer omkring $50 per användare, beroende på modell.

6.3 Övriga bedömningsgrunder

I detta avsnitt kommenteras produkten med utgångspunkt från de punkter förprodukturval som finns i tabell 3.1 på sidan 16.

6.3.1 Lämplighet för användare

Efter utvärderingen av Passage i testnätverket har jag även installerat produktenpå två arbetsstationer i företagets ordinarie nätverk. För att säkerställa att det inteskulle uppstå oväntade problem i den miljön testade jag först själv att användaPassage för inloggning på min egen arbetsstation. Eftersom detta utföll väl lät jagtre andra användare få tillgång till ett konto med enbart smartkort på en särskildarbetsstation, vilket gav värdefulla insikter i hur användare upplever inloggningmed smartkort. Erfarenheten visar att förfarandet vid inloggning med Passage ärmycket lätt att lära. Att använda ett smartkort eller en USB-enhet tillsammansmed en PIN-kod är mycket likt hanteringen av bankomater, vilket jag tror tillhörvardagen för de flesta av företagets användare. Alltså finner jag det troligt att deflesta användarna snabbt ska kunna lära sig att autentisera sig på detta sätt. Docktar autentiseringen med den version av Passage som jag testat alldeles för lång tid


för att den ska kunna accepteras av användarna då fördröjningen upplevs somfrustrerande.

Lösningen kommer att vara olika portabel beroende på om smartkort ellerUSB-enheter väljs som hårdvaruenheter. Mjukvaran och drivrutinerna kan i bådafallen installeras via CCM, men för smartkort måste kortläsare installeras på ar-betsstationerna till skillnad från USB-enheter som fungerar utan extra hårdvara.Även möjligheten att använda hårdvaruenheterna till annat än inloggning skiljersig åt beroende på vilken typ av enhet som väljs. USB-enheterna har begränsning-ar som gör att de inte kan användas som foto-ID och möjligheten att användaenheterna för inpassering är mindre än för smartkorten. Smartkorten är å andrasidan utrustade med magnetremsor som kan användas i de kortläsare för inpas-sering som finns idag. Dessutom kan korten förses med foto i särskilda skrivareför att använda dem som legitimation inom företaget. Utöver detta kan användar-na dra nytta av de funktioner för single sign-on som Passage har och även lagracertifikat för andra PKI-tillämpningar än inloggning.

6.3.2 Lämplighet för företaget

Säkerheten som Passage erbjuder är god. Lagring av nycklar och kryptografiskaoperationer stöds med upp till 2048 bitars nyckellängder, vilket ger god margi-nal för framtiden. Det är heller inte möjligt att på ett enkelt sätt komma åt privatinformation som lagrats på enheten, vilket garanteras av att den är certifierad en-ligt FIPS 140-1. Som visats är Passage även kompatibelt med de system som finnsidag. Eftersom USB-enheten inte kräver någon hårdvara förutom själva enhetenoch mjukvara och kontohantering kan skötas centralt på samma sätt som idag,ser jag inget hinder för att en autentiseringslösning baserad på denna typ av en-het skulle kunna skala till den nivå som behövs idag såväl som i framtiden. OmPassage istället används med smartkort krävs extra hårdvara i form av kortläsa-re vilket ökar kostnaderna och kräver en större arbetsinsats, vilket gör lösningenmindre skalbar. Ett sätt att minska effekten av detta vore att i framtiden köpadatormodeller eller tangentbord med inbyggda kortläsare, för att på så sätt efterhand förse alla arbetsstationer med kortläsare.

Passage erbjuder ett antal möjligheter utöver inloggning som kan vara intres-santa i framtiden, bland annat sådana som baseras på PKI och som tjänar på attkunna lagra nycklar och certifikat i säkra behållare som är knutna till använda-re. Som visats ovan är kryptering och signering av e-post ett exempel på detta.Möjligheten att lagra lösenord för applikationer och webbtjänster kan höja säker-heten ytterligare genom att mer komplexa lösenord kan väljas utan att ge använ-darna mer att komma ihåg. Detta minskar risken att lösenord skrivs ned eller attsamma lösenord används till flera applikationer. Vidare är det möjligt att lagramjukvaruenheter på smartkort för att generera engångskoder utan att ha tillgångtill SD600-enheter. Detta minskar kostnaden för den lösning för fjärrinloggningsom används idag eftersom användare som tilldelats smartkort inte behöver yt-terligare en hårdvaruenhet. Stödet för Java-applikationer på enheterna erbjuderdessutom möjligheter att utöka enheternas funktionalitet ytterligare i framtiden.

6.4 Sammanfattning av RSA Passage 53

6.4 Sammanfattning av RSA Passage

Passage erbjuder tre sätt att autentisera användare med hårdvaruenheter, certifi-katinloggning, så kallad Passageinloggning samt förautentisering med mjukva-ruenheter. De två första sätten skiljer sig inte åt ur användarnas synvinkel, dåhandhavandet är identiskt. Dock skiljer sig den underliggande tekniken åt mar-kant. Det sista sättet, att autentisera användaren med en mjukvaruenhet före Win-dowsinloggningen, innebär fler moment än inloggning med enbart lösenord ellerhårdvaruenhet, vilket försvårar för användaren. Dock har mjukvaruenheter ettvärde vid fjärrinloggning genom att det kan vara möjligt att ersätta de hårdvaru-enheter som används idag med smartkort eller USB-enheter.

Valet mellan smartkort och USB-enheter bör övervägas noga. Om företaget villanvända hårdvaruenheterna både för fysisk och digital identifikation, är smart-korten det naturliga valet. Om det anses viktigare att lösningen inte kräver extrahårdvara, bör USB-enheter väljas.

I det skick Passage är idag, är certifikatinloggning inte praktiskt användbar.Dock arbetar RSA på problemet och om det löses uppfyller denna produkt dekrav som företaget ställt och erbjuder ytterligare funktionalitet för framtiden.


Kapitel 7

Test av Rainbow iKey

I detta kapitel beskrivs produkten iKey 2032 från Rainbow Technologies. Förstges en allmän beskrivning av hur produkten används av slutanvändare samt ad-ministration av produkten och närliggande tjänster. Därefter redovisas hur pro-dukten uppfyller de krav som ställts upp och sist ges en kort genomgång av denfunktionalitet utöver kraven som produkten erbjuder.

7.1 Allmänt

Rainbow iKey är en kryptografisk hårdvaruenhet i form av en USB-nyckel. I pro-dukten ingår även programvara för hantering av enheterna och integrering avdessa i Windows inloggningsmekanismer. I det här avsnittet bekrivs hur produk-ten ser ut för användare samt hur administrationen av den går till.

7.1.1 Administration

Avsikten med detta avsnitt är att ge en överblick av administrationen av iKey. Sebilaga C för detaljer om hur installationen av produkten genomfördes och hur denkonfigurerades.

Innan en iKey går att använda måste enheten initialiseras, vilket görs via verk-tyget Token Utilities som medföljer iKey, se figur 7.1. Initialiseringen startas ge-nom ett menyval och tar några sekunder. Därefter har enheten tilldelats en förvaldPIN-kod som måste ersättas med en unik kod för varje användare. Detta kan ad-ministratören sköta från Token Utilities direkt eller så får användarna själva ordnadetta genom den Pass Phrase Utility som medföljer klientprogramvaran. Fördelenmed att sätta en personlig PIN-kod, även fast användarna själva kan ändra den ef-teråt, är att risken att den förvalda PIN-koden blir kvar på enheterna elimineras.I Token Utilities sätts även ett namn på iKeyenheten för att skilja den från andraenheter, till exempel kan namnet väljas till användarens anställningskod för attgöra det extra tydligt vem den tillhör. Administratören kan också ändra den tid

55

56 Test av Rainbow iKey

Figur 7.1. Huvudvyn i Token Utilities för iKey. Källa: Egen konstruktion

som enheten ska komma ihåg att användaren angett sin PIN-kod. Om inte privatinformation på enheten används inom denna tid kommer användaren att avkrä-vas PIN-koden på nytt nästa gång denna information behövs. Denna inställninggör att användaren slipper skriva in sin PIN-kod vid varje tillfälle som privat in-formation på enheten behöver kommas åt.

I certifikatvyn i Token Utilities, se figur 7.2, hanteras de certifikat som lagraspå enheten. I denna vy visas de behållare för certifikat som finns på enheten ochvilka certifikat de innehåller. Enheten kan lagra upp till fyra certifikat men detär endast det som ligger i den så kallade default container som kan användas förWindowsinloggning. Möjligheten finns därför att bestämma vilken av behållarnasom ska vara förvald. Begränsningen att endast ett certifikat på en kryptografiskenhet kan användas för inloggning beror på det sätt som Windows 2000 hante-rar inloggning med sådana enheter [12]. Det går även att registrera certifikatenpå datorn, vilket krävs för att kunna använda dem för kryptografiska operationeri applikationer på arbetsstationen. Det certifikat som användaren loggat in medregistreras automatiskt, men övriga måste registreras manuellt. Val för att raderacertifikat från systemet och från enheten finns även, dock är det inte möjligt attradera certifikatet både från enheten och från systemet. Ny information för kryp-tografiska operationer importeras från filer som är i PKCS #12-format, vilka blandannat kan innehålla certifikat och privata nycklar.

Genom att installera verktyget Token Utilities på klientdatorerna får användar-na möjlighet att administrera sina certifikat och enheterna på egen hand. Nackde-len med att ge användarna möjlighet att själva administrera sina enheter är att omnågon av misstag skulle välja att initialisera sin enhet så kan inte denna längreanvändas för autentisering eftersom alla certifikat som lagrats på den raderats.

Som beskrivits ovan kan certifikat och nycklar importeras till enheten men denkan även själv generera nycklar, vilket ur säkerhetssynpunkt är det bästa sättet atthantera användare med kryptografiska enheter. Eftersom nycklarna genereras in-ternt i enheten behöver den privata nyckeln aldrig lagras eller hanteras på annatsätt utanför enheten och risken att den skulle kunna fångas upp någonstans mini-meras. Utfärdandet av certifikat kan till exempel göras från särskilda stationer via

7.1 Allmänt 57

Figur 7.2. Certifikatlistan för en iKey i Token Utilities. Källa: Egen konstruktion

webbgränssnittet till Windows CA-tjänst, se figur 7.3. När en administratör enrol-lerar en användare, det vill säga tilldelar användaren ett certifikat med tillhörandenycklar, väljer denne den CSP (se avsnitt 2.3.2) som motsvarar den kryptografis-ka enheten. För iKey ska Datakey RSA CSP väljas. Nyckelgenereringen sker då iiKey-enheten som sedan skickar ut den publika nyckeln samt en digital signatur,vilket CA:n använder för att skapa motsvarande digitala certifikat. Observera attden privata nyckeln i nyckelpar som genererats i en iKey inte tillåts att exporterasfrån enheten och att det därför inte är möjligt att använda certifikatet för att sig-nera eller kryptera meddelanden om inte användarens iKeyenhet är ansluten tilldatorn. På företaget ska det dock inte vara möjligt att använda en dator utan enansluten enhet.

7.1.2 Användning

Vid inloggning till en arbetsstation med Windows 2000 möts användaren av envälkomstskärm med uppmaningen att trycka tangentkombinationen Control-Alt-Delete. Detta är en så kallad secure attention sequence och eftersom den alltid fångasupp av operativsystemet vet användaren att det lösenord denne skriver in verk-ligen går till inloggningsprocessen och inte fångas upp av något program somimiterar Windows GINA för att stjäla lösenord. När drivrutinerna för iKey in-stallerats på en arbetsstation räcker det med att ansluta enheten till en USB-port


Figur 7.3. Utfärdande av certifikat att lagras på iKey. Källa: Egen konstruktion

istället för att trycka Control-Alt-Delete. Detta indikeras i välkomstskärmen i Win-dows GINA som en liten bild av ett smartkort, se figur 7.4. När en iKeyenhet an-slutits uppmanas användaren att skriva in sin PIN-kod för enheten, se figur 7.5.Denna kod används endast av iKey och motsvarar alltså inte det lösenord som an-vändaren normalt använder eftersom autentiseringen sker med certifikat till skill-nad från autentisering med domänlösenord. När användaren autentiserats skerinloggningen som vanligt och användaren märker inte längre av skillnaden motdet vanliga förfarandet.

Figur 7.4. Windows GINA med stöd för smartkort. Källa: Egen konstruktion

Användaren kan låsa arbetsstationen och stänga av den på samma sätt somvanligt. En skillnad är att arbetsstationen även låses omedelbart när iKey-enhetentas bort från USB-porten som den anslutits till (om inloggningspolicyn konfigure-

7.2 Kravuppfyllnad 59

Figur 7.5. Inmatning av PIN i Windows GINA. Källa: Egen konstruktion

rats för detta; se bilaga C). Det är möjligt att även tillåta inloggning med vanligalösenord parallellt med certifikatinloggning, dock är det inte möjligt att låsa uppen arbetsstation med lösenord om användaren som låst datorn är inloggad meden iKey. Samma enhet måste då användas för att få tillgång till datorn igen, endasten administratör kan använda sin enhet eller lösenord för att avsluta användarenssession och frigöra arbetsstationen för användning.

Om användarens certifikat är av typen Smartcard User kan det även användasför säker e-post till skillnad från certifikat av typen Smartcard Logon som endastkan användas för inloggning. När e-postklienten, i det här fallet Outlook, konfi-gurerats för att hantera säker e-post med certifikat som lagrats på en iKey fungerardet utmärkt att skicka och ta emot signerad och krypterad e-post. När e-post skasigneras eller när krypterad e-post ska läsas krävs att användaren anger sin PIN-kod för den kryptografiska enheten eftersom det är operationer som använderden privata nyckeln. I övrigt märker användaren inte att kryptonycklarna liggerpå en iKey och inte lokalt på arbetsstationen.

7.2 Kravuppfyllnad

I detta avsnitt undersöks hur väl lösningen med iKeyenheter uppfyller de kravsom ställts upp, se tabell 4.1 på sidan 20.

7.2.1 Säkerhet

Som beskrivits i kapitel 5 uppfyller iKey kraven i kategorin Säkerhet i grundut-förandet. Undantaget är kravet på något man måste bära med sig, eftersom USB-enheten inte kan användas som fotolegitimation eller inpassering. Det senare ärdock möjligt att komplettera med om företaget så önskar.


När en användare är inloggad på en arbetsstation och tar med sig enheten kandenne använda enheten för att logga in på andra arbetsstationer, kravet på flerainloggningar är alltså uppfyllt även om endast den dator där enheten är ansluten


för tillfället kan vara upplåst. Kombinationen av kraven flera behörigheter och ing-et extra att bära på stöds däremot inte av denna lösning eftersom Windows 2000endast tillåter ett certifikat per enhet för nätverksinloggning. iKey har inte hellernågra andra mekanismer för inloggning. Användare som har flera roller i nätver-ket kommer alltså behöva en enhet per roll. Att växla identitet fungerar på sammasätt som vanligt med hjälp av Windows sekundära inloggning vilket medger attapplikationer kan köras med andra rättigheter än de den inloggade användarenhar. Detta kan även stängas av genom att Runas-tjänsten avaktiveras.

Jag har mätt tiden som inloggningsförfarandet från klientdatorn tar, både mediKeyenheten och med lösenordsinloggning mot samma användarkonto. Tidsskill-naden är helt försumbar, så att tvingas ansluta en USB-enhet hindrar inte att kra-vet på snabb inloggning uppfylls. Däremot innehåller lösningen inte någon meka-nism för att underlätta single sign-on och eftersom enheten endast kan användasför certifikatbaserad inloggning kan den inte användas för inloggning till lokalakonton. Det finns inget som hindrar lång inloggning, utan det fungerar precis somvanligt. Det är möjligt att koppla flera certifikat till samma konto för inloggning,därför går det att besöka arbetsstation och att ha en gemensam profil på arbetssta-tioner är då trivialt uppfyllt eftersom flera användare kan använda samma konto.Windows sparar information om utförda inloggningar och medger inloggning utannätverk även för certifikatbaserad inloggning på motsvarande sätt som för inlogg-ning med lösenord. Inkoppling av extern utrustning stöds inte på något enkelt sättdå mjukvara i så fall måste installeras och inloggningen på utrustningen måsteske via domänen om iKey ska användas för detta.

7.2.3 Övrigt

De flesta kraven i kategorin Övrigt är trivialt uppfyllda i och med att produktengått att installera och använda i en miljö som liknar företagets ordinarie nätverk.Kompatibelt med Active Directory uppfylls eftersom det är just Active Directory somhanterar användarkonton i testdomänen. Eftersom det är möjligt att tillåta vissakonton att använda lösenord för inloggning är detta kompatibelt med CCM sombehöver denna möjlighet för att utföra uppgifter på klientdatorerna. De operativ-system som använts i testerna är identiska med företagets servrar och klienter. Jaghar varit i kontakt med Rainbows återförsäljare Smartsec via e-post och telefonoch jag har fått snabba svar på mina frågor och har fått intrycket att de är seriösaoch måna om sina kunder. Jag har även haft telefonkontakt med en representantfrån Rainbows Europakontor i Storbritannien som svarade på mina frågor. Minbedömning är därför att kravet på support kan uppfyllas för denna produkt.

Eftersom iKey endast kräver USB vilket moderna datorer är utrustade med,krävs ingen extra hårdvara. Dock kan eventuellt ett USB-nav vara önskvärt för attunderlätta för användarna genom att göra USB-portarna mer tillgängliga. Det pa-ket med fem iKey-enheter och programvara som jag använt i mina tester kostade2000 kronor, men jag har inte begärt offert på ett större antal enheter och kandärför inte säga vilket pris som skulle vara aktuellt för skarp installation av pro-dukten.

7.3 Övriga bedömningsgrunder 61

7.3 Övriga bedömningsgrunder

I detta avsnitt kommenteras produkten med utgångspunkt från de punkter förprodukturval som finns i tabell 3.1 på sidan 16.

7.3.1 Lämplighet för användare

Vad gäller punkten Användarvänlighet, är min bedömning att produkten är myc-ket lätt att lära sig använda. Att sätta en enhet i en USB-port och ange en PIN-kodmotsvarar förfarandet vid en bankomat som jag tror att de flesta av företagetsanvändare är bekanta med. Eftersom produkten heller inte introducerar någrahinder eller kräver att det vanliga arbetet förändras tror jag att användare snabbtkan lära sig använda produkten och acceptera den som ett bra alternativ till lö-senordsinloggning. Lösningen är även högst portabel, ingen extra hårdvara ärnödvändig för att utnyttja det nya inloggningsförfarandet från en arbetsstationoch det medför även att lösningen fungerar lika bra på företagets bärbara datorer.Den mjukvara som krävs installeras via administrationssystemet CCM.

Vad gäller att använda iKey för andra ändamål än inloggning i nätverket er-bjuds inget utöver att enheten kan lagra flera certifikat, vilket kan användas i and-ra PKI-applikationer. Möjligheterna att använda en USB-enhet för inpassering el-ler som foto-ID är dock små.

7.3.2 Lämplighet för företaget

Säkerheten som iKey erbjuder relativt andra produkter är god. Alla produkterpå marknaden stöder minst 1024 bitars nycklar för RSA-operationer och iKey geräven möjligheten att använda 2048 bitars nyckellängder, vilket ger god marginalför framtiden. Det är heller inte möjligt att på ett enkelt sätt komma åt privatinformation som lagrats på enheten, vilket garanteras av att den är certifieradenligt FIPS 140-1. Som visats är iKeylösningen även kompatibel med de systemsom finns idag. Eftersom lösningen inte kräver någon hårdvara förutom självaenheten, samt att mjukvara och kontohantering kan skötas centralt på samma sättsom idag, ser jag inget hinder för att en autentiseringslösning baserad på iKeyskulle kunna skala till den nivå som behövs idag såväl som i framtiden.

De framtida möjligheter som finns är sådana som baseras på PKI och som tjä-nar på att kunna lagra nycklar och certifikat i säkra behållare som är knutna tillanvändare. Som visats ovan är kryptering och signering av e-post ett exempel pådetta.

7.4 Sammanfattning av Rainbow iKey

Den kryptografiska hårdvaruenheten iKey från Rainbow Technologies är i det ut-förande som testats avsedd för inloggning i Windows-nätverk med digitala certi-fikat. Detta klarar produkten väl samt är lätt att installera och att använda. Han-


teringen hindrar inte arbetet för användarna, och de kan sköta sina uppgifter påsamma sätt som tidigare. Utöver detta har iKey inte mycket funktionalitet att er-bjuda men utlovar heller ingenting. För inloggning och säker e-post är dock dettaen kompetent produkt som kan få ökad användbarhet i händelse av att använ-dandet av företagets PKI ökar, till exempel om företaget introducerar fler applika-tioner som utnyttjar certifikat.

Kapitel 8

Jämförelse

I detta kapitel jämförs de två produkterna, Rainbow iKey och RSA Passage, somtestats. Tonvikten i jämförelsen läggs på skillnaderna mellan produkterna så, föratt få en mer heltäckande bild av dem hänvisas till utvärderingarna som redovisasi kapitel 7 samt kapitel 6. För detaljer om de krav som nämns, se kapitel 4, samtkapitel 3 för information om stödpunkterna för produkturval.

8.1 Administration och användning

Att installera produkterna är mycket enkelt eftersom de båda använder standar-diserade installationsprogram, vilket även underlättar för att hantera installatio-nerna genom CCM. Inte heller upplevs konfiguration och inställningar som merkomplicerade eller svårhanterade i någon av produkterna. Passage erbjuder dockmallar för domäninställningar för central konfiguration av programvaran vilketunderlättar administrationen avsevärt.

Vad gäller hanteringen av produkterna för användare skiljer sig inte produk-terna åt nämnvärt. De är båda mycket enkla att lära sig att använda och medförinte några hinder i det dagliga arbetet för användarna. Produkterna skiljer sigdock åt i snabbhet då användningen av iKey är lika snabb som lösenordsinlogg-ning medan Passage i den nuvarande versionen fördröjer inloggningen så mycketatt det skulle störa arbetet.

8.2 Kravuppfyllnad

I tabell 8.1 finns en översikt över vilka krav som uppfylls av respektive produkt.Som synes är det endast ett fåtal av kraven som skiljer produkterna åt. Eftersombåda produkterna används med kryptografiska hårdvaruenheter, som stöds avWindows på ett standardiserat sätt, går de flesta kraven att uppfylla genom me-kanismer i operativsystemet. Detta är fallet då certifikatinloggning används, bete-

63

64 Jämförelse

Tabell 8.1. Jämförelse av kravuppfyllnadKravet uppfylls av:

Benämning Rainbow iKey RSA PassageNågot man har eller är Ja JaEj fast hemlighet Ja JaNågot man vet Ja JaHemlighet svår att komma åt Ja JaNågot man måste bära med sig Nej (tillval) Ja (med smartkort)Borttagande låser arbetsstation Ja JaFlera inloggningar Ja JaFlera behörigheter Ja JaInget extra att bära på Nej JaVäxla identitet Ja JaSnabb inloggning Ja NejSingle sign-on Nej JaLokala konton Nej JaLång inloggning Ja JaBesöka arbetsstation Ja JaGemensam profil Ja JaInloggning utan nätverk Ja JaInkoppling av extern utrustning Nej NejKompatibelt med Active Directory Ja JaKompatibelt med CCM Ja JaOperativsystem Ja JaSupport Ja Ja, se dock avsnitt 6.2.3.Ingen extra hårdvara Ja Ja (med USB-enhet)Pris Ej jämfört Ej jämfört


endet för till exempel borttagande av enheter bestäms genom operativsystemet el-ler domäninställningar. Därför är produkterna mycket lika vad gäller den grund-funktionalitet som krävs. Skillnaderna i kravuppfyllnad finns därför där Passageerbjuder funktionalitet utöver certifikathantering.

Skillnaderna mellan iKey och Passage, uttryckt i de krav som ställts upp, äratt det med Passage är möjligt att låta en användare ha flera inloggningsbehörig-heter på samma hårdvaruenhet vilket inte iKey stöder. Vidare erbjuder Passagemöjligheten att logga in på lokala datorkonton, och eftersom enheterna kan lagralösenord för webbtjänster och applikationer erhålls en enkel form av single sign-on. Det som talar till Passage:s nackdel är att certifikatinloggningen är så långsamatt den upplevs mycket störande.

Vidare är Passage med smartkort möjlig att använda med dagens magnetbase-rade system för inpassering. Om iKey skulle användas till detta måste istället ettradiobaserat system införas och enheterna måste då extrautrustas för detta.

8.3 Ytterligare funktionalitet 65

8.3 Ytterligare funktionalitet

Båda produkterna tillhandahåller Windowsinloggning med certifikat samt skyd-dad lagring av ytterligare certifikat på enheterna. Produkten iKey har ingen yt-terligare funktionalitet utöver detta men löser uppgiften som utlovat. Passage hardäremot funktioner utöver certifikathanteringen, bland annat lagring av lösenordsom beskrivits ovan. Dessutom kan enheterna användas tillsammans med mjuk-varuenheter för att ersätta SD600-enheter vid färrinloggning. En översikt överdetta finns i tabell 8.2. Utöver detta stöder Passage-enheterna Javaapplikationer,vilket ger näst intill obegränsade möjligheter för ytterligare användning av enhe-terna.

Tabell 8.2. Jämförelse av tekniska specifikationerSpecifikation Rainbow iKey RSA PassageKapacitet för certifikat 4 st 3 stKonton för domäninloggning – 3 stLösenord för single sign-on – 15 stKapacitet för mjukvaruenheter – 3 stTyp av enheter USB Smartkort eller USB


66 Jämförelse

Kapitel 9

Rekommendationer ochslutsatser

9.1 Rekommendationer

I detta kapitel presenteras de rekommendationer jag kan ge, baserat på de lär-domar jag dragit under projektet. Målet med projektet är att ge underlag för valav produkt för att ersätta lösenordsinloggning. Utöver detta pekar jag på någrapunkter som bör övervägas innan en sådan lösning införs.

9.1.1 Val av produkt

Den produktutvärdering jag har gjort utmynnade i en jämförelse mellan iKey 2032från Rainbow Technologies och Passage från RSA Security. Det övergripande in-trycket är att iKey är en mer mogen produkt som fungerar utan uppenbara pro-blem, medan Passage erbjuder funktionalitet som kan ge företaget stora mervär-den i framtiden.

Min rekommendation till företaget är att överväga de krav, som denna utvär-dering utgått från, och fatta beslut om hur de ska prioriteras. Om endast ett säk-rare alternativ för autentisering önskas, anser jag att iKey är den produkt som börväljas med motivering att den löser uppgiften utan att tillföra ytterligare funk-tionalitet, som ökar produktens komplexitet. Utöver inloggning med certifikat er-hålls även möjligheten att använda iKey-enheter för säker lagring av certifikat förandra ändamål.

Om företaget anser att funktionalitet utöver certifikathantering är önskvärt äriKey mindre lämplig. Passage medger här istället större flexibilitet vad gäller au-tentisering och ger dessutom möjlighet att använda hårdvaruenheterna till flerändamål i framtiden. Eftersom företaget idag använder andra lösningar från RSA,skulle Passage komplettera dessa och kanske även minska den totala kostnadenför licenser. Dock ger inte Passage ett lika stabilt helhetsintryckintryck som iKey

67

68 Rekommendationer och slutsatser

på grund av några mindre fel som inträffat och är idag inte möjlig att användaför certifikatinloggning på grund av den långa fördröjning som uppstår. Den ver-sion av Passage som jag testat var helt ny och jag anser att den släppts för tidigteftersom den är behäftad med fel. Dock är uppdateringar som åtgärdar bristernautlovade. Min uppfattning är därför att om dessa löser problemen är Passage enprodukt som både uppfyller företagets behov idag och ger stora möjligheter tillframtida tillämpningar.

Min rekommendation för val av produkt för säker autentisering är följdaktli-gen att välja iKey om endast inloggning och certifikatlagring önskas och att avvak-ta uppdateringar av Passage om dess funktionalitet önskas. I händelse att dennafunktionalitet önskas och Passage inte kan förbättras inom rimlig tid, kan det varaaktuellt att utvärdera ytterligare produkter som erbjuder liknande funktionalitetoch som kanske befinner sig i ett mer moget tillstånd av utveckling.

9.1.2 Införande av certfikatinloggning och PKI

Om PKI-baserad autentisering införs, bör det även utredas vilka användargrup-per som ska använda certifikatinloggning och tilldelas hårdvaruenheter. Jag serinte att man uppnår ett tillstånd av total säkerhet enbart genom att tilldela allaföretagets användare smartkort och inte tillåta dem att logga in med lösenord. Pågrund av begränsningar i Windows hantering av PKI-autentisering måste tekniskpersonal tillåtas att autentisera sig med lösenord även i framtiden. Bland annatkräver vissa administrativa uppgifter, som till exempel att lägga till nya datoreri domänen, att behörigheten styrks med lösenord. Detta eftersom det inte finnsstöd i nuvarande versioner av Windows för att göra detta med certifikat. Det ad-ministrativa verktyget CCM medför ytterligare krav på att lösenord finns kvar.

Vidare kan det finnas risker förknippade med att kräva att administratörerska autentiseras med hårdvaruenheter. Om det uppstår problem med hårdvaraneller PKI:n kanske det i så fall inte finns någon som kan logga in och åtgärda pro-blemen. Av denna anledning måste ändå administratörer med ansvar för certifi-kathanteringen tillåtas logga in med lösenord. Den stora vinsten anser jag därförkommer att finnas för den största delen av företagets användare, vilka endast haren behörighet i nätverket och inte utför administratörsuppgifter. Genom att krä-va att dessa användare autentiseras med hårdvaruenheter och certifikat, minskashanteringen av lösenord markant och risken att inloggningsuppgifter lämnas åt-komliga vid arbetsstationer eller är kända av flera användare minimeras.

Grunden för inloggning med certifikat är en PKI baserad på en CA för utfär-dande av certifikaten. För att detta ska fungera utan problem bör en långsiktigstrategi utarbetas först och införandet genomföras med stor eftertanke. Riskernaär annars att förtroendet hos användarna för den nya tekniken äventyras om denmedför problem för dem eller om lösningen måste revideras i efterhand. Vidarefinns en risk att förtroendet för företagets certifikat och företagets säkerhetsarbeteskadas om eventuella certifikat för signering måste återkallas på grund av en oge-nomtänkt lösning. Min rekommendation är att en välfungerande PKI bör införasinnan certifikatinloggning kan vara aktuell, åtminstone om företaget önskar utöka

9.2 Slutsatser 69

användandet av certifikaten i framtiden. Jag anser att det kan vara värdefullt förföretaget att göra detta och senare införa ytterligare PKI-applikationer som säkere-post och signering av dokument. Förutom de direkta vinsterna vad gäller ökadsäkerhet vid kommunikation inom och utom företaget, skulle detta ge signaler omatt företaget ligger i framkanten av den tekniska utvecklingen och har kompetensatt uttnyttja elektronisk kommunikation på ett säkert sätt. En vinst med att införainloggning med hårdvaruenheter är att certifikat och hårdvaruenheter introduce-ras för användarna, vilket ger dem möjlighet att vänja sig vid tekniken och ökaderas medvetenhet om kraven på säker kommunikation.

9.2 Slutsatser

Jag har genom detta projekt fått en god inblick i ett företags behov vad gällertillämpad informationssäkerhet och vikten av att användarvänligheten hålls i åtan-ke under allt säkerhetsarbete. Jag har även insett att ett projekt av den här typentar stor tid i anspråk, mycket på grund av all information som måste samlas infrån olika källor för att kunna jämföra produkter. Den som genomför ett liknandeprojekt i framtiden bör även vara förberedd på att kontakten med externa partertar mycket tid, och det går inte att räkna med snabba svar på alla frågor. Den somkommer att ha kontakt med leverantörer bör även vara påläst om företaget ochdess produkter samt vara insatt i ämnesområdet för att kunna bedöma rimlighe-ten i de svar som ges. Alla svar är inte alltid definitiva eftersom förutsättningarförändras och specifikationer uppdateras.

Vikten av att testa produkter och särskilt att jämföra olika produkter, även omde tycks likvärdiga, tycker jag också har framgått tydligt. Det är först när en pro-dukt används under realistiska förhållanden som det går att avgöra hur väl denuppfyller det som utlovats. Det har också varit tydligt att tills synes helt likvärdigfunktionalitet hos olika produkter kan ha betydande skillnader i prestanda, vilketendast kan upptäckas vid en direkt jämförelse.

Vad gäller de praktiska testerna av produkter har jag insett vikten av att ut-föra testerna i ett nyinstallerat system för att undvika att prestandan påverkas avkomplexa inställningar eller en ovanlig programmiljö. Tack vare att testerna ut-förts i ett separat nätverk med nyinstallerade datorer har produkterna givits enrättvis bedömning. Tester måste även genomföras i den riktiga målmiljön för attundersöka vilka problem som kan uppstå där.

Att utrusta användare med kryptografiska hårdvaruenheter för certifikatin-loggning är ett sätt att kunna öka nätverkssäkerheten och på sikt minska den ad-ministrativa hanteringen av lösenord. Valet av produkt för detta försvåras av attdet finns en mängd produkter som utlovar liknande funktionalitet. Det är dockfullt möjligt att hitta en produkt som uppfyller företagets behov. Jag anser ävenatt företaget har mycket att vinna på att införa certifikatbaserad inloggning föranvändare och en PKI som kommer att ha ett stort värde i framtiden. Stor efter-tanke bör iakttagas vid val av produkt och införandet av en PKI för att redan frånbörjan skapa ett förtroende för företagets säkerhetslösningar.

70 Rekommendationer och slutsatser

Litteraturförteckning

[1] ActivCard, Inc. ActivCard Gold. http://www.activcard.com/products/gold.html , 2003. Läst 2004-01-06.

[2] Ross Anderson. Security Engineering. John Wiley & Sons, 2001.

[3] Comex Electronics AB. Tillträdesskydd. http://www.comex.se/itsakerhet_tilltradesskydd.asp , 2003. Läst 2003-11-12.

[4] Commission of the European Communities. Information Technology SecurityEvaluation Criteria (ITSEC), 1991. Version 1.2.

[5] CRYPTOCard Corp. The CRYPTOCard. http://www.cryptocard.com/index.cfm?PID=136&PIDList=62,64,136&PageName=The%20CRYPTOCard, 2004. Läst 2004-01-06.

[6] Datakey Inc. Rainbow iKey 2032 series USB Token. http://www.datakey.com/products/smart_cards/products_sc_rainbow.shtml , 2003.Läst 2004-01-06.

[7] Whitfield Diffie och Martin E. Hellman. New directions in cryptography.IEEE Transactions on Information Theory, IT-22(6):644–654, 1976.

[8] DigiSAFE Pte Ltd. KeyCrypt - Cryptographic USB Token. http://www.digisafe.com/products/pc_keycrypt.html , 2002. Läst 2003-11-12.

[9] Dino Esposito. Supporting CryptoApi in Real-World Applications. http://www.microsoft.com/mind/0697/crypto.asp , 1997. Läst 2003-10-20.

[10] Dieter Gollmann. Computer Security. John Wiley & Sons, 1999.

[11] R. Housley, W. Ford, W. Polk och D. Solo. Internet X.509 Public KeyInfrastructure Certificate and CRL Profile. http://www.ietf.org/rfc/rfc2459.txt , 1999. Läst 2003-09-23.

[12] Microsoft Corporation. Microsoft Windows 2000 Server: Windows 2000 SmartCard Logon, 1999. White paper.

71

72

[13] Microsoft Corporation. Microsoft Windows Server 2003: Active Directory Tech-nical Overview, 2002. White paper.

[14] Microsoft Corporation. Certificate Enrollment Using Smart Cards.http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257480 , 2003. Läst 2003-10-16.

[15] Svetlin Nakov. How Digital Signatures Work: Digitally Signing Messages. http://www.developer.com/java/ent/print.php/3092771 , 2003. Läst2003-12-08.

[16] National Institute of Standards and Technology. Security Requirements forCryptographic Modules (FIPS PUB 140-1). http://www.itl.nist.gov/fipspubs/fip140-1.htm , 1994. Läst 2003-10-02.

[17] National Institute of Standards and Technology. Security Requirementsfor Cryptographic Modules (FIPS PUB 140-2). http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf , 2002. Läst 2003-10-15.

[18] PC/SC Workgroup. PC/SC Workgroup Specifications 1.0. http://www.pcscworkgroup.com/Specifications/SpecificationsOverview.html , 1997. Läst 2003-10-06.

[19] Rainbow Technologies. iKey 2032, Windows 2000 Smart Card Logon Integration– Administrator’s Guide, 2002. Version 1.1.2.

[20] Rainbow Technologies. IKEY 2000 OVERVIEW. http://uk.rainbow.com/products/ikey/ikey2000.asp , 2003. Läst 2003-11-12.

[21] R. Rivest. The MD5 Message-Digest Algorithm. http://www.ietf.org/rfc/rfc1321.txt , 1992. Läst 2003-09-22.

[22] RSA Security Inc. The Authentication Scorecard, 2003. White paper.

[23] RSA Security Inc. PKCS #1 – RSA Cryptography Standard. http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/ , 2003. Läst 2003-10-27.

[24] RSA Security Inc. PKCS #11 – Cryptographic Token Interface Standard. http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/ , 2003. Läst 2003-09-23.

[25] RSA Security Inc. Public-Key Cryptography Standards. http://www.rsasecurity.com/rsalabs/pkcs/ , 2003. Läst 2003-09-23.

[26] RSA Security Inc. RSA SecurID. http://www.rsasecurity.com/products/securid/smartcards.html , 2003. Läst 2003-11-12.

[27] RSA Security Inc. RSA SecurID Passage 3.5 Administrator’s Guide, 2003.

73

[28] Sun Microsystems Inc. Java Card 2.1.1 Platform Documentation. http://java.sun.com/products/javacard/specs.html , 2000. Läst 2003-10-14.

[29] The Secure Hash Algorithm Directory. MD5, SHA-1 and HMAC Re-sources. http://www.secure-hash-algorithm-md5-sha-1.co.uk/ ,2001. Läst 2003-11-12.

[30] Brian Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wrayoch J. Trostle. Public Key Cryptography for Initial Authentication inKerberos. http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-cat-kerberos-pk-init-09.txt , 1999. Läst 2003-10-16.

[31] Utimaco Safeware AG. SafeGuard Advanced Security. http://www.utimaco.com/content_products/sg_as.html , 2003. Läst 2003-11-12.

74

Bilaga A

Installation av nätverksserver

Här redovisas konfigurationen av den server som användes under testerna. Av-sikten är att det ska vara enkelt att återskapa miljön för ytterligare tester eller vidinstallation för skarp drift.

A.1 Översikt

Operativsystemet på servern är Microsoft Windows Server 2003 Standard Edition.De förvalda inställningarna under installationen ändrades inte. Efter installatio-nen lades följande serverkomponenter till:

• Active Directory (ingår i alternativet Typical)

• DNS (ingår i alternativet Typical)

• DHCP (ingår i alternativet Typical)

• Certificate Services

• IIS (Application Server)

• POP3 och SMTP (Mail Server)

A.2 Konfiguration av komponenter

Här redovisas inställningar som gjordes för de serverkomponenter som installe-rades. Vissa av dem är endast relevanta för installation i ett separat testnätverkeftersom dessa redan finns i företagets nätverk.

75

76 Installation av nätverksserver

A.2.1 Active Directory (rollen Domain Controller)

För Active Directory ställde jag in att servern skulle vara domänkontrollant fördomänen stsmain.local med NETBIOS-namn STSMAINL för att inte skapaförvirring genom att använda samma domännamn som det riktiga nätverket.

Några testanvändare skapades för att testa inloggning från klientdatorernaoch konton för klientdatorerna skapades i domänen. Detta behöver förstås integenomföras vid skarp installation eftersom domänkontrollanten för företagets nätredan är konfigurerad.

A.2.2 DNS och DHCP

Eftersom servern inte har kontakt med andra DNS-servrar valdes inställningen donot forward queries för DNS-rollen. DHCP-rollen aktiverades för att tillhandahållaIP-adresser till klientdatorerna och den förvalda IP-poolen accepterades. Dessakomponenter är även de redan konfigurerade i företagets riktiga nätverk.

A.2.3 Microsoft Management Console

För att förenkla hanteringen av tjänster relaterade till certifikathanteringen skapa-de jag en MMC med några komponenter som var mycket praktiska att ha lätt till-gängliga, se figur A.1. För att skapa en likadan MMC, skriv först kommandot mmc

Figur A.1. MMC för hantering av servertjänster. Källa: Författaren

vid en kommandoprompt. Välj menyvalet File→ Add/Remove Snap-in i det fönster

A.2 Konfiguration av komponenter 77

som kommer upp på skärmen och gå till fliken Standalone. Klicka på knappen Addså visas listan på de komponenter som går att lägga till. Välj Active Directory Usersand Computers och klicka på Add så läggs den till i listan. Välj Certification Aut-hority och därefter Local Computer för att administrera CA:n som körs på sammadator och klicka på Finish. Välj Certificates och klicka på Add. Välj därefter My useraccount för att hantera certifikat för den inloggade administratören och klicka påFinish. Avsluta konfigurationen av MMC:n och spara den med ett lämpligt namn.

A.2.4 Certificate Services

Komponenten Certificate Services gör att servern kan agera CA för företaget, vilketär nödvändigt för att kunna utfärda och hantera certifikat utan att tvingas köpatjänsten utifrån. När det frågas om vilken typ av CA som ska installeras, välj En-terprise Root CA. Som namn (common name, CN) på CA:n valde jag STStestCAför att tydliggöra att certifikat som utfärdats av denna server inte ska användas iskarpa sammanhang.

För att kunna utfärda de certifikat som behövs för inloggning med certifikatlagrade på smartkort i Windows 2000, krävs att följande certifikatmallar läggs tilli företagets CA (se även [14]):

• Smartcard Logon

• Smartcard User

• Enrollment Agent

Detta görs i konfigurationskonsollen Certification Authority som finns underAdministrative Tools på servern, eller i den MMC som skapades i avsnitt A.2.3. Ikonfigurationen för den aktuella CA:n läggs mallarna till genom att högerklickapå Certificate Templates som finns i trädvyn under namnet på CA:n. Välj därefterNew→ Certificate Template to Issue, då visas en dialog med tillgängliga mallar. VäljSmartcard Logon och klicka på OK. Upprepa detta för de övriga certifikatmallarna.

För att en administratör ska kunna utfärda certifikat åt andra användare be-höver administratören ett särskilt certifikat för detta. Öppna MMC:n från avsnittA.2.3 och expandera Certificates – Current User i trädvyn. Expandera Personal somfinns därunder och högerklicka på Certificates. Välj All Tasks → Request New Certi-ficate vilket öppnar en guide för att begära ett nytt certifikat. När frågan om typ avcertifikat kommer upp, välj Enrollment Agent och slutför guiden. När det är klartfinns det nya certifikatet i listan för den aktive användarens personliga certifikat.Dessa steg upprepas för varje administratör som ska kunna utfärda certifikat åtanvändare. Det skulle även vara möjligt att låta användare begära certifikat åt sigsjälva men det skulle skapa nya säkerhetsproblem eftersom varje användare skul-le behöva ha administratörsbehörighet.

Observera att när företaget förlitar sig på en PKI-lösning baserad på en egenCA, måste denna betraktas som ett extremt känsligt system. Obehörig åtkomst tillden kommer att leda till stora förluster eftersom det finns risk att känslig informa-tion görs åtkomlig och att förtroende för företagets certifikat skadas svårt.

78 Installation av nätverksserver

A.2.5 IIS

Eftersom jag installerade Certificate Services innan IIS installerats, skapades in-te de filer som behövs för att använda det webbgränssnitt som erbjuds för ut-färdande av certifikat. För att skapa dessa filer i efterhand anropas kommandotcertutil -vroot från en kommandoprompt. Därefter finns dessa sidor till-gängliga på adressen http://servernamn/certsrv/ , vilket gör det möjligtatt utfärda certifikat åt användare från registreringsstationer genom en webblä-sare. ASP (Active Server Pages) måste även vara ativerat i IIS för att detta skafungera.

A.2.6 POP3 och SMTP

För att kunna testa att skicka krypterad och signerad e-post konfigurerades ser-vern även som e-postserver. I händelse av en skarp installation kommer förståsföretagets egen e-postserver att användas.

Bilaga B

Installation av RSA Passage

Här redovisas hur produkten Passage konfigurerades och vilka anpassningar itestmiljön som gjordes för den. Installationsanvisningar finns i administratörs-handboken för produkten [27] men utöver detta finns här de lokala anpassningarjag gjort.

B.1 Installation av programvara

Programvaran Passage 3.5 installeras med hjälp av installationsprogrammet somfinns i toppnivån på CD:n som medföljer produkten. Övrig programvara och driv-rutiner finns i mappar på skivan. Då vissa problem med fördröjningar vid inlogg-ning uppstått under testarbetet, har jag begärt uppdateringar av programvaranoch har därför även använt version 3.5.1 av Passage, vilket är den version somkommer att säljas som färdig produkt.

B.1.1 Passage

Under installationen väljs vilka komponenter av Passage som önskas. Komponen-ten Passage Logon innehåller stöd för att logga in med användarnamn och lösenordsom lagrats på ett smartkort och är även nödvändig om inloggning med certifi-kat på smartkort önskas. För inloggning med digitala certifikat och andra tjänstersom bygger på certifikat ska dessutom komponenten Passage Cryptographic Ser-vices väljas. Komponenten Password Management innehåller funktionalitet för attlagra lösenord för applikationer och webbtjänster på smartkort, denna kompo-nent behövs alltså inte för inloggning i Windows.

När komponenterna valts frågas efter vilka konfigurationsinställningar somska gälla, se figur B.1, dessa kan dock ändras även efter att installationen genom-förts. Valet Microsoft Logon ska väljas för att möjliggöra inloggning med certifikateller vanlig domäninloggning med användarnamn och lösenord. Det andra va-let, Passage Logon, ställer in Windows GINA att använda inloggningsinformation

79

80 Installation av RSA Passage

Figur B.1. Konfiguration under installationen av Passage. Källa: Författaren

som lagrats på ett smartkort, observera att detta alltså inte är certifikatinloggning.För att underlätta för användare, som ofta utför uppgifter som kräver att kortetsPIN-kod anges, kan valet Remember PIN markeras. Då lagras kortets PIN-kod iWindowsregistret under en valbar tid efter att koden angivits första gången, deförvalda tiderna innebär att koden slutar att lagras efter 10 minuter om inte an-vändaren använder kortet och att koden maximalt kan lagras i 60 minuter. Närnågon av tiderna gått ut kommer användaren att avkrävas PIN-kod nästa gången skyddad operation på kortet ska utföras.

För att underlätta hanteringen av certifikat bör valet Register at logon för certifi-kat markeras. På detta sätt har en inloggad användare alltid tillgång till de certifi-kat som finns på dennes smartkort utan att behöva bekymra sig om de registreratseller inte.

B.1.2 Drivrutiner

Jag har använt smartkortläsaren SCR301 som ansluts via USB-gränssnitt samtSCR131 som har RS232-anslutning för att hantera smartkortet 5100. Drivrutinerför läsarna finns på CD:n och installeras med hjälp av respektive installationspro-gram. För att hantera USB-enheten 6100 krävs drivrutiner för SchlumbergerSemaReflex Reader, vilka även finns på CD:n. För dessa finns dock inget installations-program utan filerna måste packas upp och installeras med hjälp av Windows en-hetshanterare. Den drivrutin som ska installeras är e-gate Virtual Reader Enumeratoroch när det är gjort upptäcker Windows e-gate USB Smart card reader och installerardrivrutiner för denna läsare. De drivrutiner för USB-enheterna som finns på ski-van är version 1.10, vilket är den enda version som fungerar med 6100-enheterna.

B.2 Konfigurering av domänpolicy 81

Version 2.0 av Schlumbergers drivrutiner finns tillgängliga på Windows Updateoch dessa får alltså inte installeras, därför är det viktigt att att vara försiktig omtill exempel Windows funktion för automatiska uppdateringar används.

Observera att det inte är möjligt att ha stöd för både smartkortläsare och USB-enheter samtidigt på samma dator. Om detta försöks kommer systemet inte attkänna igen 5100-kortet och det blir bland annat inte möjligt att utfärda certifikatför 6100-enheterna. Endast en typ av enhet kan alltså användas på en enskild ar-betsstation.

B.1.3 Software token

Hårdvaruenheterna som medföljer Passage kan även hantera så kallade softwaretokens, det vill säga mjukvara som genom RSA:s tidssynkroniseringsteknik ge-nererar engångskoder. För att hantera lagringen av dessa på SecurID-enheternainstalleras mjukvaran Software Token for Windows Workstations som kan laddas nerfrån http://www.rsasecurity.com/download/ . Jag har testat att användadessa mjukvaruenheter tillsammans med lösenordsinloggning i Windows 2000och för detta krävs även en ACE-server samt mjukvaran ACE Agent for Windowssom även den går att ladda ner från RSA:s hemsida.

ACE-servern installerades på den server i testnätverket som även är domän-kontrollant och konfigurerades på samma sätt som den ACE-server som företagetanvänder för fjärrinloggning. Ett användarkonto skapades och ID-numren för demjukvaruenheter som användes lästes in för att aktivera dessa på ACE-servern.

På klientdatorn installerades ACE-agenten och den ställdes in att kräva au-tentisering med SecurID-enhet före Windowsinloggningen. Dessutom installera-des mjukvaran för att hantera mjukvaruenheter. När dessa förberedelser var klaratilldelades en mjukvaruenhet till den testanvändare som skapats. Detta sker frånACE-serverns administrationskonsoll genom menyvalet Token → Issue SoftwareTokens och därefter väljs vilken enhet som ska tillhöra vilken användare. Mjuk-varuenheten exporteras då till en fil som ska importeras till ett smartkort eller enUSB-enhet med hjälp av mjukvaran Software Token.

B.2 Konfigurering av domänpolicy

För att fullt dra nytta av de funktioner som inloggning med en hårdvaruenhet ger,behöver vissa inställningar i domänpolicyn göras. Detta utförs i konfigurations-konsollen Domain Security Policy som finns under Administrative Tools på servern.Inställningarna som redovisas här gäller för Windows Server 2003, motsvarandeinställningar finns under liknande namn i Windows 2000 Server.

De relevanta inställningarna finns under avdelningen Security Settings→ LocalPolicies → Security Options i trädvyn i konfigurationskonsollen. För att datorernai domänen ska låsas när hårdvaruenheterna tas bort, ska inställningen Interactivelogon: Smart card removal behaviour sättas till Lock Workstation . Om det istället

82 Installation av RSA Passage

är önskvärt att användaren ska loggas ut helt ska Force Logoff väljas. Om in-loggning med lösenord inte ska tillåtas, ska inställningen Interactive logon: Requiresmart card sättas till Enabled . Det senare är även möjligt att ställa in per använ-dare i Active Directory för större flexibilitet.

Med Passage följer även mallar för domänpolicy för de inställningar som kangöras i Control Center. För att utnyttja dessa ska en ny MMC skapas. Skriv kom-mandot mmcvid en kommandoprompt. Välj menyvalet File→Add/Remove Snap-ini det fönster som kommer upp på skärmen och gå till fliken Standalone. Klicka påknappen Add så visas listan på de komponenter som går att lägga till. Välj GroupPolicy Object Editor och bläddra till Default Domain Policy och avsluta konfiguratio-nen. Högerklicka på Administrative Templates som finns under Computer Configura-tion och välj Add/Remove Templates. Bläddra till och välj den av konfigurationsmal-larna från Passage-CD:n som önskas. Högerklicka på den policygrupp som ladestill och välj View → Filtering och avmarkera valet Only show policy settings that canbe fully managed.

B.3 Konfigurering av Microsoft Outlook

För att använda Outlook för säker e-post måste detta först ställas in, de inställning-ar som beskrivs här gäller för Outlook 2002. Välj Tools → Options från menyradenoch välj fliken Security. Klicka på knappen Settings för att skapa inställningar försäker e-post. I rullistan som heter Secure Message Format väljs vilket format försäkra meddelanden som ska användas. S/MIME är den vanligaste standardenpå Internet vilket gör det troligt att meddelanden som skickas i detta format kanhanteras av de flesta mottagare. Det andra valet är Exchange Server Security vil-ket förutsätter att certifikaten hanteras av en Exchangeserver och certifikaten ärdå i ett format som endast kan hanteras av andra användare som också använderdenna tjänst. För att kunna skicka krypterad e-post som med hög sannolikhet skakunna läsas av mottagare utanför företaget bör alternativet S/MIME väljas.

När meddelandeformatet valts ska de certifikat som ska användas för signe-ring och kryptering av meddelanden väljas. Bredvid namnrutan för respektivecertifikat finns en knapp, Choose, och genom att trycka på den visas vilka certi-fikat som kan väljas. Den sista inställningen som bör göras är att kryssa i valetSend these certificates with signed messages eftersom det då räcker att skicka ett sig-nerat meddelande till en mottagare för att denne ska få tillgång till avsändarenscertifikat. När mottagaren får ett signerat meddelande kan denne välja att lagracertifikaten i sin adressbok och kan, efter att ha verifierat att meddelandet komfrån rätt person, därefter lita på att signerade meddelanden kommer från den av-sändaren.

Bilaga C

Installation av Rainbow iKey

Här redovisas hur produkten iKey konfigurerades och vilka anpassningar i test-miljön som gjordes för den. Installationsanvisningar finns i administratörshand-boken för produkten [19] men utöver detta finns här de lokala anpassningar jaggjort.

C.1 Installation av programvara

På alla datorer som ska hantera iKey-enheter måste mjukvarustöd installeras. Påde stationer som ska användas för att enrollera användare, det vill säga att till-dela dem certifikat på respektive iKey-enhet, installeras lämpligen programvaraniKey 2000 Authentication Solution och på klientdatorer väljs Client Software. Bådainstallationerna startas från menyn på CD:n som medföljer iKey.

C.1.1 Authentication Solution

På skärmen som heter CIP Options väljs vilka komponenter som ska installeraspå datorn. För att Windows 2000-inloggning ska fungera måste valen ActivateWindows 2000 logon samt Start CIP during Windows startup vara markerade. Påde datorer som ska kunna initialisera enheter och ändra inställningar på demska även Token Utilities väljas för installation. Gå igenom resten av installations-guiden och avsluta den. Därefter måste den senaste drivrutinen för iKey instal-leras, innan detta är gjort känns inte enheten igen av Windows. Jag har använtversion 3.4.5 som i skrivande stund finns på ftp://anonftp.rainbow.com/support/IKEYDRVR.EXE . Observera att detta steg inte nämns i administratörs-handledningen.

Efter installationen måste en iKey-enhet stoppas i en ledig USB-port på datorn.Detta sätter igång registreringen av ny hårdvara i Windows som därefter kommeratt känna igen iKey-enheter när de används. Efter att dessa steg är genomförda

83

84 Installation av Rainbow iKey

kommer hädanefter en symbol i form av ett smartkort att visas på Windows in-loggningsskärm.

C.1.2 Client Software

Detta installationsprogram visar ingen dialog utan utförs helt utan interaktion.Därför kan detta val till exempel vara lämpligt att använda för automatisk instal-lation via CCM. Installationen motsvarar att valen Activate Windows 2000 logonsamt Start CIP during Windows startup markeras i installationen som beskrevs iavsnitt C.1.1 och är tillräcklig för klientdatorer. Dock måste även den nya drivru-tinen installeras efteråt.

C.2 Konfigurering av domänpolicy

För att fullt dra nytta av de funktioner som inloggning med en hårdvaruenhet ger,behöver vissa inställningar i domänpolicyn göras. Detta utförs i konfigurations-konsollen Domain Security Policy som finns under Administrative Tools på servern.Inställningarna som redovisas här gäller för Windows Server 2003, motsvarandeinställningar finns under liknande namn i Windows 2000 Server.

De relevanta inställningarna finns under avdelningen Security Settings→ LocalPolicies → Security Options i trädvyn i konfigurationskonsollen. För att datorernai domänen ska låsas när hårdvaruenheterna tas bort, ska inställningen Interactivelogon: Smart card removal behaviour sättas till Lock Workstation . Om det iställetär önskvärt att användaren ska loggas ut helt ska Force Logoff väljas. Om in-loggning med lösenord inte ska tillåtas, ska inställningen Interactive logon: Requiresmart card sättas till Enabled . Det senare är även möjligt att ställa in per använ-dare i Active Directory för större flexibilitet.

C.3 Konfigurering av Microsoft Outlook

För att använda Outlook för säker e-post måste detta först ställas in, de inställning-ar som beskrivs här gäller för Outlook 2002. Välj Tools → Options från menyradenoch välj fliken Security. Klicka på knappen Settings för att skapa inställningar försäker e-post. I rullistan som heter Secure Message Format väljs vilket format försäkra meddelanden som ska användas. S/MIME är den vanligaste standardenpå Internet vilket gör det troligt att meddelanden som skickas i detta format kanhanteras av de flesta mottagare. Det andra valet är Exchange Server Security vil-ket förutsätter att certifikaten hanteras av en Exchangeserver och certifikaten ärdå i ett format som endast kan hanteras av andra användare som också använderdenna tjänst. För att kunna skicka krypterad e-post som med hög sannolikhet skakunna läsas av mottagare utanför företaget bör alternativet S/MIME väljas.

När meddelandeformatet valts ska de certifikat som ska användas för signe-ring och kryptering av meddelanden väljas. Bredvid namnrutan för respektive

C.3 Konfigurering av Microsoft Outlook 85

certifikat finns en knapp, Choose, och genom att trycka på den visas vilka certi-fikat som kan väljas. Den sista inställningen som bör göras är att kryssa i valetSend these certificates with signed messages eftersom det då räcker att skicka ett sig-nerat meddelande till en mottagare för att denne ska få tillgång till avsändarenscertifikat. När mottagaren får ett signerat meddelande kan denne välja att lagracertifikaten i sin adressbok och kan, efter att ha verifierat att meddelandet komfrån rätt person, därefter lita på att signerade meddelanden kommer från den av-sändaren.

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© 2004, Mattias Backman

http://www.ep.liu.se

http://www.ep.liu.se

Documents

Utvärdering av produkter för säker autentisering i ...19491/FULLTEXT01.pdf · with people concerned have been carried out. The demands which re-sulted from the interviews have