Stærk autentifikation ved SmartCards og Biometriske metoder

Datalogi Institut ved Københavns Universitet Juni 2002 Stærk autentifikation ved SmartCards og Biometriske metoder Udarbejdet af: Orod Badjelan orod@diku.dk Vejleder: Klaus Hansen

Af Orod Badjelan, DIKU juni 2002 2 Indholdsfortegnelse INDHOLDSFORTEGNELSE...2 1 INDLEDNING...5 2 AUTENTIFIKATION...6 2.1 AUTENTIFIKATION I DEN VIRKELIGE VERDEN...6 2.2 FORSKELLIGE FORMER (ALTERNATIVER) FOR AUTENTIFIKATION...6 2.2.1 Noget B og S ved...7 2.2.2 Hvad B gør...7 2.2.3 Hvor B er...7 2.2.4 Hvem B er...8 2.2.5 Noget B har...8 2.3 AUTENTIFIKATION I DEN DIGITALE VERDEN...8 2.3.1 Autentifikation ved hjælp af password...9 2.3.2 Biometrikker...11 2.3.3 Elektroniske nøgler...14 3 STÆRK AUTENTIFIKATION...17 4 SMARTCARDS...19 4.1 SMARTCARD HARDWARE...19 4.2 SMARTCARD KOMMUNIKATIONSMODEL...21 5 JAVACARD...23 5.1 JAVACARD ARKITEKTUR...23 5.2 JAVACARD SPROGSUBSÆT...24 5.3 JAVACARD VIRTUEL MASKINE (JCVM)...25 5.4 JAVACARD RUNTIME ENVIRONMENT (JCRE)...25 5.5 JAVACARD API...26 5.6 APPLET-METODER...26 5.7 JCRES UNDERSØGELSE AF KOMMANDO APDU-HEADER...27 5.8 APDU-METODER...28 5.9 UNDTAGELSER...28 5.10 SIKKERHED...29 5.10.1 Sikkerhedsmekanismer i JavaCard...29 5.10.2 Transient og persistente Objekter...29 5.10.3 Transaktioner...30 5.10.4 Applet firewall...31 5.10.5 Objektdeling...31 5.10.6 Offcard verificering...32 5.10.7 Kryptografi...33 6 DESIGNOVERVEJELSER OG BEGRÆNSNINGER...34 6.1 LØSNING AF PROBLEMERNE MED HENSYN TIL HARDWARE...34 6.2 LØSNING AF PROBLEMER MED HENSYN TIL SOFTWARE...34 6.3 KRAVSPECIFIKATION...36 6.4 OVERORDNET DESIGN...36 6.4.1 Pin-kode...37 6.4.2 Trevejs Handshake...37 6.4.3 Etablering af en sikker kommunikationslinje...41 6.4.4 BrugerAutentifikation...42 7 IMPLEMENTERING OG PROGRAMBESKRIVELSE...45 2

Af Orod Badjelan, DIKU juni 2002 3 7.1 DESIGN OG IMPLEMENTERING AF KRYPTOGRAFISKE OBJEKTER...45 7.1.1 Problemer ved anvendelse af abstrakte klasser i JCCA...47 7.1.2 Implementering af Factory-klasser...47 7.1.3 Design og implementering af ALG_RSA_NO_PAD...48 7.1.4 Design og implementering af ALG_DES_CBC_NO_PAD...50 7.1.5 Design og implementering af ALG_SHA...51 7.1.6 Design og implementering af ALG_RSA_SHA_PKCS1...52 7.2 DESIGN OG IMPLEMENTERING AF KORTSPECIFIKKE APPLIKATIONER...53 7.2.1 Design og implementering af Appletten StrongAuthentification...53 7.2.2 Design og implementering af Mutual_Loyality...54 7.2.3 Design og implementering af User_Authentication...54 7.3 DESIGN OG IMPLEMENTERING AF HOSTSPECIFIKKE APPLIKATIONER...55 7.3.1 Design og implementering af myapi...55 7.3.2 Design og implementering af Mutual_Loyality...56 7.3.3 Design og implementering af User_Authentication...57 7.3.4 Design og implementering af host...57 7.3.5 Design og implementering af den grafiske grænseflade...58 8 AFPRØVNING OG BRUGERVEJLEDNING...60 9 AFSLUTNING...68 LITTERATUR LISTE...69 BILAG A...70 ISO 7816 STANDARD...70 BILAG B...71 KRYPTOGRAFI...71 HVAD ER KRYPTOGRAFI...71 SYMMETRISK KRYPTERING (PRIVAT NØGLE)...72 ASYMMETRISK KRYPTERING (OFFENTLIG NØGLE)...73 HASH FUNKTION...75 DIGITAL UNDERSKRIFT...75 NØGLEFORDELING...76 WEB TRAFIKSIKKERHED...77 BILAG C...79 ORDFORKLARING...79 BILAG D...81 KONSOL UDDATA...81 BILAG E...84 STATUS WORD...84 PROJEKTSPECIFIKKE STATUSORD...84 ISO 7816 STATUSORD...85 BILAG F...86 INSTALLATIONSVEJLEDNING...86 INSTALLERING AF JAVACARD...86 3

Af Orod Badjelan, DIKU juni 2002 4 INSTALLERING AF PROTOTYPEN STRONG AUTHENTIFICATION...87 BILAG G...88 PROGRAMTEKST...88 KORTS APPLIKATIONER...88 STRONGAUTHENTIFICATION.JAVA...88 MUTUAL_LOYALITY.JAVA...93 USER_AUTHENTICATION.JAVA...96 FINGER_PRINT_TEMPLET.JAVA...97 MAKEDESKEY.JAVA...98 CONVERTER.JAVA...99 KORTETS KRYPTOGRAFISKE APPLIKATIONER...100 CIPHERFACTORY.JAVA...100 MESSAGEDIGESTFACTORY.JAVA...101 SIGNATUREFACTORY.JAVA...102 ALG_RSA_NO_PAD.JAVA...103 Card_RSAPrivateKey.java...105 Card_RSAPublicKey.java...106 CA_RSAPublicKey.java...107 Host_RSAPublicKey.java...108 ALG_DES_CBC_NO_PAD.JAVA...109 DES_KEY.java...111 ALG_SHA.JAVA...112 ALG_RSA_SHA_PKCS1.JAVA...114 HOST APPLIKATIONER...116 MYAPI.JAVA... 116 MUTUAL_LOYALITY.JAVA...121 RANDOM.JAVA...125 CONVERT.JAVA...126 USER_AUTHENTICATION.JAVA...127 Finger_Print_Sampel.Java...128 HOST.JAVA...130 SAS.JAVA...133 GENERICWINDOWLISTENER.JAVA...137 INFO.JAVA...138 BONUSFRAME.JAVA...138 PICT.JAVA...139 HOSTENS KRYPTOGRAFISKE APPLIKATIONER...141 CIPHERFACTORY.JAVA...141 MESSAGEDIGESTFACTORY.JAVA...142 SIGNATUREFACTORY.JAVA...143 ALG_RSA_NO_PAD.JAVA...144 Host_RSAPrivateKey.java...146 Host_RSAPublicKey.java...147 CA_RSAPublicKey.java...148 Card_RSAPublicKey.java...149 ALG_DES_CBC_NO_PAD.JAVA...150 DES_KEY.java...152 ALG_SHA.JAVA...153 ALG_RSA_SHA_PKCS1.JAVA...155 4

Af Orod Badjelan, DIKU juni 2002 5 1 Indledning For at kunne snakke om autentifikation, er det nødvendigt at forklare hvad der egentlig menes, når ordet autentifikation nævnes, og hvad der adskiller det fra ordet identifikation. Vi ved alle sammen hvordan indrejsen og udrejsen fra et land kontrolleres i en international lufthavn, hvor alle skal stå i kø for at komme gennem de forskellige former for sikkerhedskontrol. Lad os benytte en sådan lufthavn som udgangspunkt til forklaring af disse ord. Når passagererne møder op i lufthavnen, henvender de sig til boardingpass kontoret for at aflevere deres billetter og modtage boardingpasset der udpeger den siddeplads i flyvemaskinen som de får tildelt. Denne fase kan betragtes som identifikation, hvor passageren kun bliver identificeret ud fra billetten. Læg mærke til at billetten kunne være stjålet. Dette betragtes ikke som et stort problem, så længe der rejses indenrigs, da risikoen antages at være acceptabel. Hvis rejsen går til udlandet, skal passageren forbi paskontrol. Der skal han både vise sit boardingpass ( identifikation) og sit pas (autentifikation) til paskontrollen. Passet er et officielt dokument der indeholder ejerens personlige oplysninger og et billede der er blevet stemplet af en autoriseret myndighed der autentificerer ejeren som en lovlig person der kan rejse til udlandet. Derudover kan passet indeholde et visum der bekræfter adgangstilladelse til specifikke lande. Identifikation og autentifikation på et datasystem kan sammenlignes med en sådan anordning. Man ønsker at sikre sine computere mod uautoriseret adgang, og selvfølgelig er dette lettest ved at tvinge brugeren til at autentificere sig selv gennem en login fase og så prøve at sortere i hvem der må komme ind og hvem der ikke må, og dem der må skal kun kunne bruge ressourcerne i det omfang deres adgangsrettigheder tillader det. Selvfølgelig kan identifikation og autentifikation undgås, hvis computeren kobles af fra omverdenen (netværket) og anbringes i et fysisk beskyttet rum hvor det kun er dens ejer der har adgang til den. Dette vil svare til en der vil bruge resten af sit liv i sit eget hus uden at komme ud i verden. Autentifikation ved hjælp af password medfører en del vanskeligheder. I dette dokument præsenteres andre alternativer som med fordel kan benyttes i stedet. Næste afsnit vil gennemgå fordele og ulemper ved anvendelse af de andre alternativer. 5

Af Orod Badjelan, DIKU juni 2002 6 2 Autentifikation Ordet autentifikation frembringer en række spørgsmål. Hvad er autentifikation egentlig, hvorfor er der brug for autentifikation, hvordan autentificerer en person sig selv over for andre i den virkelige verden og hvilke krav er nødvendige for at opnå en succesfuld autentifikation? I dette kapitel gennemgås de fundamentale begreber og mekanismer omkring autentifikation mens ovennævnte spørgsmål besvares. Kapitlet opdeles i tre underkapitler: autentifikation i den virkelige verden, forskellige former for autentifikation og til sidst autentifikation i den digitale verden. 2.1 Autentifikation i den virkelige verden Da der er i opgavens indledning er givet et eksempel på autentifikation i den virkelige verden (lufthavns eksemplet), vil dette afsnit beskrive betydningen af ordet autentifikation yderligere i relation til den virkelige verden. Hvad er autentifikation? Autentifikation er den proces hvor en person eller en maskine (S) verificerer modpartnerens identitet (B). I den virkelige verden er der f.eks. ingen der vil ansætte en medarbejder uden kendskab til hans uddannelse, straffeattest osv. Sygesikringsbeviset skal med, når lægen besøges og kørekortet er absolut nødvendigt, hvis man kører i bil og bliver stoppet af politiet. Hvorfor er autentifikation så nødvendigt i den virkelige verden? Der findes primært to grunde: Vedkommendes (B) identitet er en parameter for hans adgangsrettigheder. Vedkommendes (B) identitet bliver brugt for at holde øje med ham (registrering). F.eks. bliver kørekortet brugt til at autentificere en borger som værende berettiget til at føre et køretøj. Men det kan også bruges til at registrere færdselsovertrædelser. 2.2 Forskellige former (alternativer) for autentifikation S kan autentificere B på flere forskellige måder. Det er ikke altid nødvendigt at (B) benytter sig af et formelt dokument for at bevise sin identitet. Afhængig af situationen og miljøet kan B autentificeres ved hjælp af følgende muligheder. Noget B og S ved (B og S deler en hemmelighed) Hvad B gør (B autentificeres på baggrund af noget han gør som andre har svært ved at efterligne) Hvor B er (B autentificeres på baggrund af hvor han befinder sig) 6

Af Orod Badjelan, DIKU juni 2002 7 Hvem B er (B s fysiske egenskaber) Noget B har (f.eks. en nøgle) 2.2.1 Noget B og S ved Da jeg var soldat skulle vi skiftes til at holde nattevagt. Der skiftedes vagt ved at hviske et kodeord til den soldat som skulle afløses. På den måde blev den nye soldat verificeret over for den gamle soldat og vagten kunne gives videre. Metoden var til dels god nok, men under krigen skete det at fjenden havde aflyttet kodenavnet. I den digitale verden bruges ofte en autentifikationsmetode der er baseret på en hemmelighed der kun er delt mellem brugeren og serverapplikationen (herefter kaldet serveren). Et godt eksempel kan være brug af brugernavn og password (fordele og ulemper ved password bliver gennemgået i næste kapitel). Et andet alternativ kan være brugerens fødselsdato, brugerens mors pigenavn og eventuelt noget der er personligt og er ikke kendt af andre. Man kan godt se at denne metode er delvis risikabel, fordi når hemmeligheden afsløres er der ingen beskyttelse tilbage. 2.2.2 Hvad B gør Ofte foretrækkes nogle mekanismer som både kan gentages og er specifikke for en individuel person. Underskrifter er et godt eksempel i den virkelige verden hvor man kan forbinde et dokument med en person eller verificere vedkommendes underskrift ved sammenligning med et andet eksemplar af underskriften. I den digitale verden har man også fundet nogle metoder hvor serveren f.eks. kan verificere en bruger ud fra indtastningshastigheden (hvor mange tegn per sekund) eller fingertryks presset på tastaturen. Det er klart at præcision af disse systemer ville være afhængig af brugerens psykiske tilstand. Desuden kan man ved hjælp af træning efterligne disse signaturer så godt som man kan efterligne en andens underskrift. 2.2.3 Hvor B er I nogle tilfælde kræves der at autentificering kun kan gennemføres fra et bestemt sted. En soldat kan modtage et gevær udelukkende hvis han henvender sig til et våbendepot (det kan ikke bestilles med postordre). Denne metode kan kun benyttes hvis fysisk adgangskontrol er mulig. Da det ikke altid er muligt at forbinde en bruger til et bestemt sted, er denne form for autentifikation ikke særlig brugbar, men hvis muligheden er til stede vil en sammensætning af beliggenhed og en anden form for autentifikation forstærke autentifikationsmekanismen. F.eks. kan en operatør kun logge ind i de vigtige dele af systemet med sit operatørpassword, fra operatørrummet. 7

Af Orod Badjelan, DIKU juni 2002 8 2.2.4 Hvem B er Der findes en række mønstre i menneskets krop der adskiller sig fra person til person. Politiet kan identificere et brændt lig udfra tandkortet 1 og ved hjælp af fingeraftryk kan de identificere forbrydere. Mennesker har gennem årene brugt flere forskellige dele af kroppen til identifikation. Videnskabelige resultater viser at chancen for at finde to ens DNA hos to forskellige personer er ret lille (med undtagelse af enæggede tvillinger). Biometrikker er en stærk faktor for identifikation og autentifikation af mennesker da de er en del af menneskets krop og derfor kan de (som regel) ikke kopieres. Efterfølgende kapitler ser nærmere på biometrikker og deres indflydelse på den elektroniske verden 2. 2.2.5 Noget B har Autentifikation af en person kan ske ved hjælp af noget personen har. Dette kan f.eks. være en systemnøgle til et skab. En systemnøgle kan ikke kopieres og derfor er det kun personen der har nøglen som kan låse skabet op. Således har den person som har nøglen ansvaret for skabets indhold. Hvis noget bliver stjålet, er det nøgleholderen der er ansvarlig. Dette system giver faktisk en perfekt sikkerhed med den undtagelse hvor nøglen kan lånes ud (eller bliver stjålet). Der findes en række elektroniske nøgler af denne form der erstatter metalnøglen. Der er således det problem tilbage at man kan kopiere næsten alt i den digitale verden hvor kopien er fuldstændig ens med originalen. Der findes flere forskellige alternativer til at beskytte integritet af elektroniske nøgler. Kreditkort, SmartCard, ibutton og Javaring er forskellige former af disse nøgler. Efterfølgende kapitler uddyber yderligere disse elektroniske redskaber og sammenligner deres fordele og ulemper. 2.3 Autentifikation i den digitale verden Forrige kapitel præsenterede forskellige måder hvorpå man kan benytte autentifikation af en person i den virkelige verden. I den digitale verden kan man næsten benytte sig af alle disse former lige så godt. Følgende vil gennemgå de tilfælder hvor man benytter password, biometrikker og elektroniske nøgler til autentifikation. 1 Dette er under forudsætning af at der eksisterer et tandkort for den afdøde, hvilket kun sker hvis personen har fået specielle behandlinger såsom tandfyldning hos en tandlæge. Dvs. at metoden kan ikke bruges til verificering af personer der kun har raske og ubehandlede tænder. 2 Afsnit 2.3.2 ser nærmere på de forskellige biometrikker (herunder : DNA, øjemønstre (Retina/iris), håndgeometri, fingeraftryk, ansigtsmønstre og stemmemønstre) 8

Af Orod Badjelan, DIKU juni 2002 9 2.3.1 Autentifikation ved hjælp af password Autentifikation ved hjælp af brugernavn og password er en meget anvendt metode. Denne metode kræver ikke særligt udstyr ud over selve datamaskinen. Typisk bliver man bedt om at indtaste sit brugernavn og password. Computeren slår brugernavnet op i sin passwordfil. Hvis det er et gyldigt brugernavn vil den sammenligne det tilsvarende password i passwordfilen med det indtastede password. I det tilfælde hvor de to matcher, får man adgang til systemet. Moderne operativsystemer (f.eks. Unix) benytter sig af kryptografiske algoritmer, hash funktioner og shadowfilen for at beskytte og hemmeligholde passwordfilen og dens indhold. Der findes også en række gode råd angående valg af et stærkt password som læseren selv kan studere i [CS]. Men uanset hvor stærkt passwordet er og hvor godt operativ systemet passer på password filen; et autentifikationssystem baseret på brugernavn og password betragtes som et svagt autentifikationssystem. Et sådan system er svagt fordi hele systemet er baseret på en enkelt hemmelighed. Hvis hemmeligheden afsløres til en tredje part, eksisterer sikkerheden ikke mere. En person vil afsløre hemmeligheden, hvis hun/han bliver truet på livet. Derudover findes adskillige metoder til at få fat på et password uden at ejeren får det at vide: Passwordgætteri Passwordsnyderi (spoofing) Kompromittering af passwordfilen 2.3.1.1 Passwordgætteri Det er ikke umuligt at gætte et svagt password. Når der oprettes en konto, tildeles et default password og mange skriver det ofte i deres kalender. Derefter går der lidt tid, inden de ændrer det. En person med lidt kendskab til systemet kender som regel det default-password. Hvis f.eks. systemadministratoren ikke ændrer default-passwordet ( system ) efter installationen af et nyt program, kan en anden overtage roots rettigheder. Den gruppe af mennesker der vælger at ændre deres password ændrer det typisk til noget de nemt kan huske f.eks. mors navn, fødselsdag dato, kærestes navn osv. I disse tilfælde er en ven i stand til hurtigt at gætte et sådant password. [CS] anbefaler en række metoder til at undgå konstruktionen af denne type password. 2.3.1.2 Passwordsnyderi (spoofing) Denne type af angreb kræver lidt ekstra kendskab til computeren. Hvis hackeren selv er en berettiget bruger af systemet kan han installere et falsk login-vindue på computeren, hvor den først skriver (kopierer) brugerens brugernavn og password til en fil og derefter logger vedkommende ind i systemet. 9

Af Orod Badjelan, DIKU juni 2002 10 Hvis hackeren ikke har adgang til systemet kan han aflytte tastaturet, eller i tilfælde af fjern login kan han aflytte kommunikationslinjen (Telnet og rlogin sender passwordet i klartekst). 2.3.1.3 Kompromittering af passwordfilen Et specielt tilfælde af passwordgætteri er det tilfælde hvor hackeren er i stand til at få fat i password filen. Typisk vil hackeren kopiere password filen til en anden computer hvor hun/han så kan angribe den i et afslappet miljø. Der findes to typer angreb mod password filen: Brute force attack : Denne metode går ud på at gennemgå alle mulige password (fra A-Z). Forudsætter at der benyttes en hurtig maskine. 3 Dictionary attack : Her vælges kun en del af de mulige kombinationer (alle ord i en ordbog) som benyttes til angreb på systemet. Der findes en række beskyttelsesmetoder mod nogle af de ovennævnte angreb, men disse metoder sikrer ikke systemet 100% mod angreb[cs]. Derudover skal der tages højde for at man ikke kan holde en hemmelighed for evigt. For hver gang man benytter sit password vokser chancen for at passwordet bliver opsnappet. Ifølge Shannons teori [CTP] kan en perfekt hemmeligholdelse kun opnås, hvis man benytter en nøgle (password) én enkelt gang( one-time pad key ) 4. Det vil sige at man skal ændre sit password hver gang man bruger det og huske at det skal have en stor længde (i tilfælde af brute force attack ) og ikke være sammensat af tegn der tilsammen udgøre et menneskeligt ord der giver en betydning (mht. dictionary attack ). Det er besværligt men ikke helt umuligt at konstruere et sådan password, men er menneskets hukommelse stærk nok til at huske sådan et password?. Fordele og ulemper ved password løsning er følgende: Fordele Det er billigt og nemt. Ulemper Ofte vælger folk svage password (nemme at huske). Password har typisk en kort længde dvs. kan gættes eller knækkes. Det kan gives videre til andre. Det bliver brugt flere gange. Det bliver gemt i passwordfilen på serveren ( brute force eller dictionary angreb). Password spoofing. 3 I 1977 konkluderede Diffie & Hellman at en maskine med 1 mill. chips, hver i stand til at teste 1 mill. nøgler i sekundet, kan teste 2 56 nøgler i løbet af 20 timer. I 1999 annoncerede en gruppe studerende at de har brudt en DES-nøgle på 22 timer. Iflg. Moore s lov kan man knække en 56-bit nøgle i år 2002 med udstyr til 20.000 $ inden for 3,5 time. [AC] 4 En hel tilfældig engangsnøgle som skal have det samme længde som klarteksten. Systemet blev første gang introduceret af Gilbert Vernam i 1917 for kryptering af telegrambeskeder, men der gik 30 år indtil Shannon bevist at den kan ikke knækkes. 10

Af Orod Badjelan, DIKU juni 2002 11 2.3.2 Biometrikker Mennesket er af naturen skabt med mange enestående biologiske karakteristika (biometrikker) der gør det muligt for os at genkende hinanden i hverdagen. Når disse karakteristika benyttes i den digitale verden til identifikation, er der brug for en række algoritmer der kan genkende og matche dem. Derudover er der også brug for en række udstyr der kan læse disse karakteristika ind i computeren, men på trods af den høje pris har de den fordel at man ikke behøver at huske de lange password og endvidere kan man ikke videregive dem frivilligt til andre. Der findes mange metoder og algoritmer til dette formål, men typisk benyttes en af de nedenstående biologiske karakteristika: DNA sample: DNA er en genetisk unik faktor (undtagen for enæggede tvillinger) der findes i hver celle i et levende væsen. Et system der anvender DNA samples til autentifikation kræver hver gang en dråbe blod af brugeren for at lave et billede af DNA strukturen til at sammenligne med DNA templaten. Øjemønster (hornhinde /iris): Øjnene er også en unik biometrisk faktor. Man kan autentificere brugerens ved at undersøge øjnene både med hensyn til iris og hornhinde (retina): Hornhinde (eng. Retina): I denne metode opnås data ved at sende infrarøde stråler direkte gennem pupillen. Det reflekterede spejlbillede opfanges via et CCD kamera som sender billedet til en computer for analyse og viderebehandling. Iris: Systemets virkemåde er den samme som for hornhinden. Her er det muligt at holde apparatet i længere afstand fra øjet (i modsætning til hornhinden) og samtidig begrænses mængden af stråling (mindre farligt) idet systemet jo er nemmere. Håndgeometri: Systemet er baseret på tredimensional måling af hånden eller nogle dele af hånden f.eks. fingerlængde, fingerdiameter, fingerradius. En unik autentifikation kan opnås via brug af kun få målinger (f.eks. fem) [SCH]. Man anvender typisk infrarøde LEDer og fotodioder i systemet. Fingeraftryk: Politiet har anvendt fingeraftryk i mange år. Som regel i dette system sammenligner man reference mønstre ifølge Henrys klassifikationsssystem: buer (eng. arches), løkker (eng. loops) og kranse (eng. whorls). Type, position og orienteration af 20 af disse mønstre bliver gemt og data bliver brugt til at skabe reference mønstre. Ansigtsmønstre: Erfaring viser at menneskets ansigt er et godt kendetegn at bruge til biometrisk identifikation, men der er også en del tekniske vanskeligheder da ansigtet ændrer sig med tiden. Mennesker får makeup, overskæg, ny frisure, skæg osv. For at kunne genkende den rigtige person bag billedet skal man anvende dyre computere og avanceret værktøjer. Stemmemønstre: Her danner systemet et spektrum der er karakteristisk for en bruger via udførelsen af Fourier analyse på brugerens stemmes bølgelængde. 11

Af Orod Badjelan, DIKU juni 2002 12 Valget af hvilken metode der skal benyttes afhænger af det sikkerhedsniveau der vil opnås og hvor mange penge der er til rådighed. I listen over biologiske karakteristika listes den dyreste metode (DNA) øverst og den billigste metode (stemme mønster) nederst. Ved hjælp af en almindelig mikrofon og en billig algoritme kan man skabe et system der kan verificere en stemme. Til gengæld er det også nemt at optage en anden stemme og udnytte rettighederne. Tværtimod er der ikke mange der kan kopiere en DNA sample, men der er nok ikke mange der har lyst til at give blod hver gang de vil benytter deres computer. Fingeraftryk genkendelse er den mest brugte og sikreste metode som er blevet anvendt mange år før udbredelsen af computeren. En almindelig fingeraftryks scanner kan efterhånden købes for en fornuftig pris (ca.1000 kr.), og den nødvendige software (kun til Windows) følger også med i pakken. Kvaliteten af sikkerheden afhænger af hvor dyr scanneren er og hvilken algoritme der benyttes 5. 2.3.2.1 Biometriske systemers virkemåde Uanset hvilken karakteristika der benyttes, virker biometriske systemer næsten på samme måde. Det starter med at den pågældende biometriske karakteristik scannes ind i computeren ved hjælp af et biometrisk udstyr, hvor der dannes en biometrisk sample. De informationer der bliver udregnet fra en (eller flere) biometriske samples bliver brugt til at oprette en biometrisk template. En person bliver autentificeret når en indeværende biometriske sample matcher den tilsvarende biometriske template. Både biometriske samples og biometriske templates bliver kaldt biometriske data eller biometrisk information. Et automatisk system der kan samle, distribuere, gemme og behandle biometriske data bliver kaldt et biometrisk system. En typisk autentifikationsproces der benytter biometrisk teknologi indeholder følgende trin: 1. Opsamle de biometriske data ved hjælp af et aflæsningsudstyr. 2. Evaluere kvaliteten af de aflæste biometriske data og genaflæse dem hvis det er nødvendigt. 3. Behandle de aflæste biometriske data og danne en biometrisk template. 4. Sammenligne den biometriske sample med en (eller flere) tidligere definerede templates. I det tilfælde at der eksisterer en match, kan dette match betragtes som en verifikation eller en identifikation. Nedenstående figur viser denne gennemgang. 5 Der findes også avancerede fingeraftryksscannere der har varmesensorer indbygget. 12

Af Orod Badjelan, DIKU juni 2002 13 Figur 2.1 Autentifikationsprocess ved brug af biometrikker I dette system ses at der er brug for en database til at gemme biometriske templates (server løsning). Det vil sige at hvis serveren bliver udsat for angreb, er der risiko for at udefra kommende får fat på disse templates. Biometrikker er enestående og de kan erstatte de lange passwords, men på den anden side er de ikke særlig hemmelige, da disse dele af kroppen ikke kan gemmes for omverdenen. F.eks. kan et ansigt fotograferes, stemmen kan optages på bånd og et billede af fingeraftrykket kan genskabes ved hjælp af moderne teknologi 6. De eksisterende systemer der anvender billigt udstyr bruger normalt en kombination af den biometriske sample sammen med en anden form for autentifikation (f.eks. pin- kode) til at forstærke autentifikationsmekanismen. Fordele og ulemper ved biometriske autentifikationsløsninger kan opdeles som følger: Fordele Man skal ikke huske lange passwords. De er unikke. De er sikre mod dictionary angreb. Ulemper Biometriske templates bliver gemt i en database på serveren (kan udsættes for angreb). De er ikke hemmelige (en forfalsket kopi kan anvendes i de billige løsninger). 6 Det skal bemærkes at dette ikke gælder for alt biometriske udstyr, f.eks. kan en 3D fingeraftryks scanner gemme flere oplysninger end en 2D scanner. Med en 3D scanner kan dybden af rynkerne måles. Derfor er det vanskeligere at snyde en 3D scanner med et 2D billede. 13

Af Orod Badjelan, DIKU juni 2002 14 2.3.3 Elektroniske nøgler Elektroniske nøgler er meget udbredt til autentifikation i den digitale verden 7. Fordelen ved brug af en fysisk nøgle er at kun den person der holder nøglen i hånden får adgang til systemet (helst ejeren). Det vil sige at kun en person ad gangen kan bruge nøglen. På markedet findes generelt to typer af elektroniske nøgler; memory-nøgler og processor-nøgler: 2.3.3.1 Memory-nøgler Memory nøgler er de mest typisk anvendte elektroniske nøgler. Som navnet antyder, har disse nøgler kapacitet til at gemme personlige oplysninger (typisk de lange password filer) i sig selv. Da disse enheder ikke har beregningsegenskaber, kan de kun bruges i forbindelse med serverløsninger; dvs. at der skal være en server til rådighed (og typisk en database) for at kunne behandle de gemte data på nøglen. Afhængigt af deres funktionalitet bliver disse enheder opdelt i de to nedenstående kategorier. 2.3.3.1.1 Read only memory -nøgler Disse nøgler bliver typisk kun brugt med henblik på adgang til et system 8. Dankort er et godt eksempel på denne slags nøgler. Alle har lagt mærke til den magnetiske stribe der står bag Dankortet. Dette magnetiske felt indeholder kortnummer og brugerens ID. Ved brug af kortet i en dankortautomat skal der indtastes en pinkode (der kan glemmes eller videregives). Pinkoden krypteres med en 3-DES nøgle som er er aftalt mellem automaten og PBS (en kort symmetrisk nøgle der bliver brugt flere gang). Den krypterede pinkode sendes sammen med kortoplysningerne til en central database hos PBS for autentifikation af brugeren. Hvis dankortautomaten bliver udsat for hackerangreb under transaktionen, kan fortrolige oplysninger blive stjålet. Derudover foreligger altid risikoen for at den centrale database bliver udsat for angreb. Fordele Man skal ikke huske de lange passwords. De er sikre mod dictionary angreb. Kun den person der har nøglen kan få adgang. Ulemper Nøglen bliver også gemt i en database på serveren (kan udsættes for angreb). Hemmeligheden kan afsløres hvis kommunikationslinjen bliver aflyttet. 7 Elektroniske nøgler er et vidt begreb der dækker forskellige former for elektronisk udstyr der bliver anvendt til autentifikation. Som eksempel kan man pege på magnetstribekort, chipkort, SmartCards, ibuttons osv. 8 Der findes også forskellige typer af disse nøgler f.eks. magnetstribekort, chipkort, ibuttons osv. Her vil vi kun kigge på dankort, som alle er bekendt med. 14

Af Orod Badjelan, DIKU juni 2002 15 2.3.3.1.2 Read/Write memory -nøgler Denne type nøgle bliver typisk anvendt som en diskette (bare i mindre format), hvor man kan opdatere de lagrede oplysninger løbende. Et godt eksempel på denne type nøgler er telekort, hvor saldo oplysninger bliver opdateret af telefonboksen under samtalen. I denne slags nøgler (elektroniske udstyr) har man benyttet sig af persistent memory 9. Den bliver ikke slettet når strømmen afbrydes. Derfor har man mulighed for at opdatere hukommelsens indhold når udstyret er koblet til systemet. Man benytter typisk ikke dette system til at få adgang til computersystemer, men hvis man valgte at gøre det ville de have kapacitet til at gemme en ny nøgle hver gang. Det vil sige at i modsætning til read only nøgler (Dankortet) kan serveren hver gang installere en ny nøgle i udstyret til brug for næste gang. Dette kan øge systemsikkerheden mht. Shannons engangsnøgle teori. Ulemper ved dette system er det samme som ved read only nøgler, hvor systemet er baseret på en server løsning. Derudover kan udstyret også blive udsat for tyveri. Fordele Man skal ikke huske de lange passwords. De er sikre mod dictionary angreb. Kun den person der har nøglen kan få adgang. Der gives mulighed for at gemme (og anvende) en ny nøgle ved hver transaktion. Ulemper Nøglen bliver også gemt i en database på serveren (kan udsættes for angreb). Hemmeligheden kan afsløres ved aflytning af kommunikationslinjen. 2.3.3.2 Processornøgler Denne gruppe nøgler er microcomputere baseret på en enkelt chip løsning. De integrerer alle dele, dvs. CPU, RAM, ROM og EEPROM i en enhed. Der findes forskellige typer af disse nøgler. Eksempler på disse typer er SmartCards, ibuttons, Javaring osv. Da forskellen mellem disse typer nøgler kun ligger i deres udseende og deres styrker, vil jeg nøjes med at gennemgå en af dem (SmartCards). Fordelen ved denne type nøgle i forhold til memory-nøgler er at de giver mulighed for at beregne de kryptografiske funktioner i kortet. Ved hjælp af en udfordring/svar ( Challenge/response ) mekanisme behøver nøglen aldrig forlade kortet. Denne mekanisme vil eliminere risikoen for at nøglen bliver aflyttet via kommunikations linjen. Samtidig undgås at systemet gemmer den symmetriske nøgle i databasen. En simpel verificering af kortet ville have nedenstående konstruktion: 9 persistent memory = vedvarende hukommelse. 15

Af Orod Badjelan, DIKU juni 2002 16 1. Systemet sender en opgave (udfordring) til kortet. 2. Kortet modtager og behandler opgaven ( f.eks. krypterer det vha. sin private 10 nøgle) og sender svaret tilbage (respons). 3. Systemet dekrypterer svaret (respons) og sammenligner det med sin behandling af opgaven. Hvis der er match, vil systemet verificere kortet. I næste kapitel beskrives processornøgledesignet (SmartCards) nærmere, i det en del af opgaveløsningen er baseret på denne teknologi. Her afrundes emnet med en liste over fordele og ulemper ved brug af processornøgler: Fordele De lange passwords skal ikke huskes. De er sikre mod dictionary -angreb. Kun en person kan bruge dem ad gangen. Mulighed for at gemme (og anvende) en ny nøgle ved hver transaktion. Nøglen behøver ikke blive gemt i en database på serveren (den bliver på kortet). Hemmeligheden bliver ikke afsløret ved aflytning af kommunikationslinjen. Ulemper Det er dyrt og det kræver ekstra udstyr. Den kan videregives til andre. 10 Her mindes private nøglen i et asymmetri kryptring algortitme f.eks. RSA 16

Af Orod Badjelan, DIKU juni 2002 17 3 Stærk autentifikation Indtil nu har jeg beskrevet problemstillingerne ved password-baseret autentifikation (svag autentifikation) og fordele/ulemper er diskuteret ved de andre alternativer for autentifikationen (se kap. 2). I dette kapitel ses nærmere på hvordan fordelene ved de nævnte mekanismer kan kombineres og skabe et stærkt autentifikationssystem. Et stærkt autentifikationssystem er et system der kan eliminere (eller neutralisere) de ulemper og svagheder der blev gennemgået i kapitel 2. Derfor skal et sådant system kunne opfylde følgende betingelser: Nøglen skal være stor nok (ca. 700 cifre), så den ikke kan afsløres vha. bruteforce angreb. Brugeren behøver ikke huske de lange nøgler. Nøglerne skal ikke gemmes på serveren (forsvar mod hackerangreb og dictionary-angreb). Det vil sige at verifikationen skal ske hos klienten. Det skal ikke være muligt for hackeren at udregne nøglen ved aflytning af kommunikationslinjen mellem klienten og serveren. Nøglen må ikke kunne videregives til andre. Hver nøgle skal bindes biologisk til en bestemt bruger. For at opfylde disse krav kan SmartCards kombineres med en af de biometriske løsninger. Under afsnittet processornøgler blev det afklaret at en SmartCard løsning ville løse de fleste problemer der var ved de password- baserede autentifikationssystemer. Da nøglen i praksis bliver gemt på kortet, er kortet i stand til at udføre verifikation og de nødvendige kryptografiske beregninger vha. sin processorkraft. Det vil sige at alt vil foregå på kortet. Dette system er næsten perfekt men der er stadigvæk en risiko for at nøglen kan blive stjålet eller videregives til en uautoriseret bruger. Biometrikker kan i denne sammenhæng hjælpe os med at identificere den berettigede kortholder. I modsætning til biometriske systemer der gemmer den biometriske template ind i en database på serveren (trussel for hacker angreb) kan man gemme dem i kortet, hvor ingen kan få adgang til dem. Hvis disse templates ikke fylder meget, kan man sagtens undersøge det korrekte match af dem og den indkommende biometriske sample i kortet. Dette vil også løse problemerne med serverens integritet. I det tilfælde hvor man ønsker ekstra sikkerhed, kan man også kombinere den biometriske løsning (i kortet) med en pinkode. Udfordringen er nu at udvælge de biometrikker der vil egne sig bedst til denne løsning. Der skal tages hensyn til at lagerpladsen på kortet er begrænset. Ved hjælp af de moderne algoritmer kan man opnå unikke fingeraftrykstemplates af størrelsen 160 byte. Dette gør fingeraftryk til den bedste biometriske løsning til SmartCards. Den bedste måde hvorpå ejeren kan identificere sig selv over for kortet, vil være et kort der har en integreret fingeraftryksscanner i selve kortet. Da disse typer af kort ikke er økonomiske og endnu ikke udbredte, er den næstbedste løsning at man sørger for at kortlæseren og fingeraftryksscanneren 17

Af Orod Badjelan, DIKU juni 2002 18 har direkte kommunikation til hinanden (uden server interaktion) idet man gerne vil bruge fingeraftrykket til at bevise sin integritet over for kortet og ikke til serveren. Hvis denne linje ikke er sikker, burde man skabe en sikker linje vha. en sikker kommunikationsprotokol (f.eks. ssh). I nedenstående pseudokode er der antaget at kommunikationslinjen er sikret: 1. Kortejeren indfører sit kort ind i en kortlæser og sætter samtidigt sin finger på fingeraftryksscanneren. 2. Kortet bliver identificeret af kortlæseren hvorpå kortlæseren sender kortets IDnr. videre til hosten. 3. Fingeraftryksscanneren laver en biometrisk sample ud fra det scannede billede og sender den til kortet. 4. Verifikationsalgoritmen 11 henter sin biometriske template og sammenligner den med den indkommende biometriske sample. Hvis der er match, bliver ejeren af kortet verificeret af kortet. 5. Serveren sender en challenge (eventuelt et tal) til kortet. 6. Kortet behandler denne challenge og sender sit response tilbage til serveren. 7. Serveren behandler også selv challengen. Hvis resultatet og kortets response er ens, vil serveren autentificere kortet som en berettiget bruger. 8. Brugeren benytter systemet til at udføre den ønskede service. 9. Kommunikationen afsluttes, når man fjerner sit kort fra kortlæseren. 11 Her menes fingeraftrykverifikationsalgoritme og ikke den verifikationsalgoritme der bliver brugt til at behandle challenges fra serveren. 18

Af Orod Badjelan, DIKU juni 2002 19 4 SmartCards Et SmartCard 12 er et kort med en chip, hvor chippen er en mikrocomputer med programmerbar hukommelse. Standard størrelse på et SmartCard er på størrelse med et almindeligt kredit kort 13. Kortet består af nogle kontakter samt eventuelt en magnetstribe og/eller reliefskrift 14 (se figur 4.1). Figur 4.1 Smartcards fysiske opbygning På grund af størrelsen af et SmartCard,er det kun specieldesignede chips, der kan bruges. Den form for mikrocomputer, man benytter i dag i SmartCards, er en enkelt-chip løsning, der integrerer alle dele, dvs. CPU, ROM, EEPROM og RAM i en enhed. 4.1 SmartCard Hardware I dette kapitel kigges der nærmere på de komponenter der bliver brugt i et typisk SmartCard. SmartCards kontaktpunkt Der er som standard otte kontakter på et SmartCard 15, som benævnes C1-C8 og bruges til at kommunikere med kortlæseren. C4 og C8 (RFU) bliver foreløbig ikke brugt til noget og er reserveret til fremtidigt brug, C1 (Vcc) bliver brugt til at føre strøm til kortet, C2 (RST) til reset af kortet, C3 (CLK) angiver clock-frekvensen på kortet (dvs. processorens clock-frekvens bliver bestemt af kortlæseren), C5 (GND) er til jord, C6 (Vpp) leverer strøm til den vedvarende hukommelse i de 12 SmartCards er et stort begreb der dækker både memorykort og mikroprocessorkort. Derudover findes der to typer af kortet Contact Cards og Contactless Cards. Her vil jeg udelukkende beskæftiger mig med mikroprocessorkort med kontakter, når jeg senere skal bruge dem i opgaven. 13 Ifølge ISO 7810 er dimensionerne 85,6 mm x 54 mm, med en hjørneradius på 3,18 mm og en tykkelse på 0,76 mm. 14 For yderligere oplysninger henvises til ISO 7811, ISO 7813 og ISO 7816. 15 Ifølge part 2 i ISO 7816. 19

Af Orod Badjelan, DIKU juni 2002 20 ældre kort (i de ældre modeller skulle spændingsniveauet ændres for at programmere EEPROM) og C7 (I/O) bliver brugt til transport af data. CPU I de mest udbredte SmartCards chips er CPU en en 8-bit mikrokontroller, der typisk bruger et Motorola 6805 eller Intel 8051 instruktionssæt med en clockprocessor på 5MHz. Hurtigere kort har inkluderet en clock multiplikator (med 2, 4 eller 8 faktor) der tillader kortet at operere med en hastighed op til 40MHz. De nyere SmartCard-chips har en 16-bit eller 32-bit mikrokontroller, hvor nogle af dem benytter RISC arkitektur. I de kommende år vil brug af disse typer kort blive mere almindelig. De typer SmartCards der bliver brugt til sikkerhed har ofte en indbygget co-processor der kan udføre de komplicerede kryptografiske beregninger. ROM SmartCards ROM (read only memory) indeholder operativsystemrutiner og permanente data der bliver brændt af kortproducenten på kortet under produktion af kortet (maskering). EEPROM Denne type hukommelse har ligesom ROM den egenskab at den ikke bliver slettet når kortet trækkes ud af kortlæseren (når strømmen bliver afbrudt) men i modsætning til ROM kan indholdet af EEPROM et modificeres under normal brug af kortet. Derfor bliver EEPROM et tit brugt til datalagring. Dvs. at de kan anvendes som harddisk på en PC. RAM RAM bliver brugt som en midlertidig arbejdsplads for lagring og modificering af data. Skrivning til RAM er 10000 gang hurtigere end skrivning til EEPROM 16 men til gengæld bliver indholdet her slettet når strømmen bliver afbrudt. 16 En erstatning eller supplement for EEPROM i de nyere kort er anvendelse af Flash EEPROM eller FRAM. Skrivning til disse typer af EEPROM er ca. 1000 gange hurtigere end skrivning til de traditionelle EEPROM.[SCH] 20

Af Orod Badjelan, DIKU juni 2002 21 4.2 SmartCard kommunikationsmodel Dette afsnit beskæftiger sig med, hvordan kommunikationen foregår og er struktureret imellem et SmartCard og en host (igennem en kortlæser (CAD 17 ) ). Kommunikationen mellem kortet og hosten foregår på en halv-duplex måde dvs. at data kan enten sendes eller modtages mellem dem, men kan ikke sendes og modtages samtidig. Når to computere kommunikerer med hinanden, udveksler de datapakker som bliver lavet ifølge en protokol (f.eks. TCP/IP). På den samme måde taler SmartCards med hosten via deres egen protokol APDU 18. En APDU indeholder enten en kommando eller en svar -pakke. SmartCards benytter master/slave modellen. Det vil sige at kortet har altid den passive (slave) rolle, hvor den afventer en APDU kommando fra hosten (master). Når kortet modtager en sådan APDU kommando, udfører den de specifikke instruktioner i det og sender et svar APDU til hosten med de ønskede services. figur 4.2 illustrerer denne kommunikationsmodel. Figur 4.2 smartcards kommunikationsmodel Protokoller Der findes mange forskellige transportprotokoller (TPDU 19 ) til udveksling af APDUer mellem kortet (klienten) og hosten (serveren). De to mest anvendte protokoller er T=0 og T=1. Begge protokoller er asynkrone og halv-duplex, hvor T=1 er blokorienteret mens T=0 protokollen er byteorienteret. Derfor er den TPDUstruktur der bliver brugt i T=1 forskellig fra den der bliv brugt i T=0. Da dette projekt vil benytte T=0 -protokollen, gives følgende en kort beskrivelse af T=0 protokol og dens APDU-struktur. 17 CAD = card acceptance device 18 APDU = application protocol data units. ISO 7816-4 19 TPDU = transmission protocol data unit; Der findes forskellige typer fra T1-T15. ISO 7816-3 21

Af Orod Badjelan, DIKU juni 2002 22 Kommando APDU Som allerede nævnt er T=0 protokollen en halv-duplex protokol. Derfor er det altid terminalen/ kortlæseren der starter kommunikationen ved at sende en kommando APDU til kortet. En kommando APDU i T=0 protokollen består af to dele: en obligatorisk header og en betinget krop. Obligatoriske header Betinget krop CLA INS P1 P2 Lc Data Le Tabel 4.1 : Kommando APDU Som det kan ses i tabel 4.1 består den obligatoriske header af fire adskilte byte: CLA: Klassebyte der angiver hvilken klasse der skal kaldes (1 byte). INS: Instruktionsbyte der peger på hvilken metode/instruktion i klassen der skal kaldes (1byte). P1: Første parameterbyte der kan gives med til den valgte metode (1 byte). P2: Anden parameterbyte der også kan gives med til den valgte metode (1 byte). Den betingede del af APDU kommandoen er afhængig af hvilken type kommandoer der bliver sendt til kortet. De fleste kommandoer er enten indkommende eller udgående set fra kortets perspektiv: Lc: Angiver længden af de indkommende data per byte (1 byte). Data: Indkommende data som længden (kan variere fra 0 til max) skal angives i Lc. Le: Angiver længden af de forventede data (fra hosten) i svar APDU (1 byte). Svar APDU Svar APDU bliver sendt fra kortet som en reaktion på en kommando APDU. Et svar APDU består også af en betinget og en obligatorisk del. Betinget del (krop) Obligatoriske dele (trailer) Data SW1 SW2 Tabel 4.2: Svar APDU Den betingede del af svar APDU er den data hosten har bedt om i kommando-apduen og længden af data er angivet i Le feltet. De obligatoriske dele angiver status for processoren i kortet efter udførelse af kommandoen. Dvs. at de vil give en besked om hvorvidt kommandoen blev udført korrekt eller ej (eventuel et hexadecimalt tal som kan fortolkes af hosten). F.eks. ordet 0x9000 betyder at kommandoen er udført korrekt. 22

Af Orod Badjelan, DIKU juni 2002 23 5 JavaCard JavaCard er en begrænset version af sproget Java 20, der blev designet til at kunne køre på mindre arkitektur herunder SmartCards, ibuttons osv. Ideen bag designet af JavaCard API var at programmøren skulle kunne implementere sine applikationer uden at være afhængig af specifikke maskin/kort koder. JavaCard har ændret sig betydeligt fra sin første version 21 (v.1.0, 1996), men det skal forstås på den måde at den stadigvæk er under udvikling 22. I dette kapitel vil vi kun kigge på en delmængde af den nuværende version (v.2.1.1 SUN 2001) der vil blive anvendt i projektet. 5.1 JavaCard Arkitektur Før JavaCard, bestod et SmartCard af to komponenter, der oftest smeltede sammen til en komponent: et operativsystem samt den applikation der skulle bruges på SmartCardet (se figur 5.1). Oftest var begge dele skrevet i maskinafhængig kode eller også kunne det API, operativsystemet stillede til rådighed, kun bruges på det bestemte kort. Der var ingen standard for hvilke funktioner operativsystemet skulle stille til rådighed, hvilket betød at API et var tæt knyttet til den teknologi som det specifikke SmartCard understøttede. Figur 5.1 SmartCard arkitektur JavaCard har ændret på den struktur, ved at benytte en virtuel maskine, der ligger ovenpå det maskinafhængige operativsystem og eksekvere bytecode 23. Ovenpå denne virtuelle maskine sidder JavaCard API 24, skrevet i Java, der gemmer det underliggende lag kompleksitet for programmøren. 20 Se afsnit 5.2 for JavaCards begrænsninger. 21 Udviklet af en gruppe ingeniører fra Schlumberger i november 1996. 22 Man kan forestille sig en stor interessant værktøjskasse med mange tomme skuffer. 23 Koden er kompileret til et mellemstadie kaldet op-code, som derefter kan eksekveres af Javas virtuelle maskine. 24 Javacard API blev standardiseret i 1997 da Schlumberger slog sig sammen med andre store virksomheder på området (Bull, Gemplus og Sun) og dannede JavaCard Forum. 23

Af Orod Badjelan, DIKU juni 2002 24 figur 5.2 viser denne arkitektur. Figur 5.2 JavaCard arkitektur 5.2 JavaCard sprogsubsæt JavaCard er en delmængde af sproget Java. Således er der valgt at medtage vigtige funktionaliteter fra Java med omhu. Programmerne kan stadig kompileres med standard Java kompilere, men på grund af begrænset mængde hukommelse og processor kraft, har designerne valgt at lave begrænsninger på nogle af de basale egenskaber ved Java. F.eks. må der maksimalt være 127 instansmetoder i en klasse (inklusive nedarvede metoder), instanser af klasser må maksimalt have 2555 bytes i deres datafelter og arrays må ikke være større end 32767 felter. Helt specifikt understøtter JavaCard ikke dynamisk klasse loading, sikkerhedsmanager, tråde og synkronisering, kloning af objekter, garbage collection og finalization. Nedstående tabel skitserer de understøttede og de ikke understøttede faciliteter af JavaCard. Understøttede Javafaciliteter Primitive datatyper: boolean, byte, short Objekter En-dimensionale arrays Packages, klasser, interface og undtagelser Νedarvning, virtuelle metoder, overloading, dynamisk oprettelse af objekter, access scope og binding regler. Ιnt nøgleord og 32-bit heltal datatype understøttes kun af få leverandører. 25 Ikke-Understøttede Javafaciliteter Store datatyper: long, double, float osv. Char og string Multi-dimensionale arrays Dynamisk klasse loadning Security manager Garbage collection og finalization Tråd Objekt serialization Objekt kloning Tabel 5.1 JavaCards begrænsninger 25 SUNs udgave af JavaCard (v. 2.1.2) som er blevet anvendt i dette projekt understøtter ikke datatypen integrer. 24

Af Orod Badjelan, DIKU juni 2002 25 5.3 JavaCard virtuel maskine (JCVM) JavaCard virtuel maskine er den enhed der sørger for at en applet bliver kørt på kortet. Den største forskel mellem JavaCard virtuel maskine (JCVM) og Java virtuel maskine (JVM) er at JCVM er implementeret som to separate dele: off-card VM og on-card VM (se figur 5.3). Konverteren der konverterer en applet (*.class) til en bytecode repræsentation (*.cap) er placeret på en arbejdsstation (off-card VM). Fortolkeren der søger for at CAP-filen bliver lagt på kortet og kørt korrekt ligger på kortet (on-card VM) 26. On-card VM sørger for hukommelseallokering, styring af objekter og vil sørge for sikkerhed under programafvikling (eng. runtime security ). Figur 5.3 JavaCard virtuelmaskine 5.4 JavaCard Runtime Environment (JCRE) JavaCard runtime environment er en sammensætning af JavaCard systemkomponenter der kører ind i et SmartCard. JCRE er ansvarlig for kortets ressource management, netværks kommunikation, applet kørsel, applet sikkerhed og on-card systemet, mens den virker som SmartCards operativsystemet. JCRE indeholder JavaCard virtuel maskine (on-card delen), JavaCard applikations framework klasser (APIs), industrispecifikke udvidelser og JavaCards systemklasser. En skitse over denne arkitektur kan ses i figur 5.2 (afsnit 5.1). JCVM blev introduceret i sidste afsnit. I næste afsnit vil vi se nærmere på JavaCards APIs klasser som er de mest betydningsfulde for JavaCard-applets programmører. 26 En dybere forklaring af hver enkelt komponent i JCVM findes i JavaCards virtuelle maskine specifikation (se litteraturliste). 25

Af Orod Badjelan, DIKU juni 2002 26 5.5 JavaCard API JavaCard API består af en række klasser for programmering af SmartCard applikationer der er designet efter ISO 7816 modellen (Se bilag A). Disse klasser er meget kompakte og kortfattede. En Javaprogrammør kan nemt se at der er mange vigtige klasser der ikke er understøttet af JavaCard 27 enten fordi de ikke passer i JavaCard designet (f.eks. GUI) eller på grund af kapacitetsbegrænsninger. JavaCard API indeholder fire nedenstående pakker: java.lang indeholder de fundamentale JavaCard klasser, som er et subsæt 28 af Java. javacard.framework er kernen på kortet. Det definerer klasser som Applet, PIN, APDU og System. Klassen Applet stiller en ramme til rådighed for kørsel af applet og interaktion med JCRE. Klasse APDU sørger for protokol uafhængige data transmission. Klasse System bestemmer en interface der sørger for systemadfærd f.eks. håndtering af APDU er og deling af objekter. javacard.security indeholder de abstrakt klasser og interfaces som brugeren må benytte til implementering af JavaCards sikkerhedsframework. javacardx.crypto er reserveret til implementering af diverse kryptografiske funktioner. De sidste to pakker har ikke nogen brugbare funktioner men de stiller en del abstrakte klasser til rådighed (eller til besvær) for programmøren mht. implementering af kryptografiske funktioner. 29 5.6 Applet-metoder For at JCRE kan styre de forskellige applets, ligger der i JavaCard API en beskrivelse af hvilke metoder en applet skal indeholde 30. Applettens konstruktør skal altid registrere appletten til JCRE ved at kalde metoden register( ). Hermed tildeler JCRE et unikt AID til den givne applet, og JCRE kan nu aktivere appletten. Alle appletter er en udvidelse af superklassen Applet og bygger på følgende fire metoder: install ( ): Obligatorisk metode, der overskriver superklassens tilsvarende metode. Denne metode installerer den aktuelle applet og skal som minimum oprette en ny instans af klassen. select( ): Denne metode er frivillig. Den bliver kaldt af JCRE, når denne fra omverdenen modtager et ønske om at kommunikere med den givne applet. Metoden kan bruges til at initialisere appletten og kan evt. afvise aktiveringen. 27 Eksempler på disse klasser er: GUI interface, Netværk I/O og desktop file systemet I/O. 28 Understøttede klasser er Objekt, Throwable og nogle JCVM relaterede Exceptions. 29 JavaCard s kryptografiske arkitektur (JCCA) vil blive gennemgået senere i kap. 7 afsnit 7.1 30 Se samtidig på applettet StrongAuthentication i bilag G 26