Sikker overføring av data med kryptering i WWW og E-mail

Trond Løvereide

I forrige utgave av HØit [1] ble de grunnleggende prinsippene i kryptografi og PGPs anvendelse av disse kort beskrevet av undertegnede. I denne utgaven skal jeg gå litt videre og se på noen andre viktige sider ved kryptografi, bl.a. sertifisering av nøkler og standarder. Men først en kort gjennomgang av noen grunnleggende begreper for de som ikke leste forrige artikkel.

En-nøkkel og to-nøkkelalgoritmer

Kryptering har vist seg som det eneste virkelige gode alternativet for å sikre seg mot at uvedkommende leser, endrer eller forfalsker elektroniske meldinger overført via ulike nettverk.
De to grunnleggende typer kryptering er en-nøkkel (eller symmetrisk) kryptering, og to-nøkkel (eller offentlig nøkkel) kryptering. Ved kryptering med en nøkkel må avsender og mottager ha den samme nøkkelen K for å kommunisere, og det kreves at denne nøkkelen kan overføres på en sikker måte slik at uvedkomne ikke kan få tak i den. Avsenderen gjør teksten til en chiffertekst med en kjent matematisk algoritme som bruker den hemmelige nøkkelen, og chifferteksten sendes til mottageren. Mottageren bruker den samme nøkkelen og en invers algoritme og gjenskaper teksten. En sniklytter som får tak i chifferteksten klarer ikke å gjenskape teksten fordi han ikke kjenner nøkkelen. Utfordringen til denne typen kryptering er å få overført nøkkelen på en sikker måte.
Usikker overføring i denne sammenheng betyr at det kan finnes personer som kan lese og kanskje også endre meldingen under overføringen.

Figur 1. Symmetrisk kryptering. Ved bruk av to-nøkkelalgoritmer har hver bruker en offentlig nøkkel P og en hemmelig nøkkel S. Den offentlige nøkkelen kan fritt publiseres og distribueres og denne brukes når man skal kryptere en tekst. Nøkkelen brukes til å lage en chiffertekst av teksten, men kan ikke brukes til å gjenskape teksten fra chifferteksten.
Til dekrypteringen trenger man den hemmelige nøkkelen som mottageren holder for seg selv. Det betyr at ingen andre enn den rette mottageren kan dekryptere chifferteksten, for han er den eneste som har den hemmelige nøkkelen. Det kan også bemerkes at de kjente to-nøkkelalgoritmene er såpass beregningskrevende at de blir ineffektive ved overføring av større tekster (filer). Da benyttes isteden en symmetrisk algoritme for selve krypteringen og to-nøkkelalgoritmen brukes til å overføre en nøkkel til den symmetriske algoritmen. Dette gjøres f.eks i SSL som brukes av Netscape og som beskrives litt senere.

Figur 2. Public-key kryptering.

To-nøkkel algoritmer kan også brukes for signering og autentisering, dvs at man kan bekrefte avsenderens identitet og sikre at meldingen ikke er endret under overføring. Da krypteres teksten eller et sammendrag av teksten (message digest) med avsenderens hemmelige nøkkel. Mottageren dekrypterer sammendraget med avsenderens offentlige nøkkel og sammenligner med et sammendrag han lager selv. Dersom disse to sammendragene er like får han bekreftet identiteten til avsenderen og at meldingen ikke er endret underveis.

Figur 3. Signering og kontroll. For en litt lenger innføring i kryptografi henvises til [1] eller [2]. Som en grundigere innføring i kryptografi og en oppdatert oversikt over bruk av kryptering på internett anbefales [9].

Nøkkelhåndtering og sertifikater

I de fleste praktiske systemer brukes nå en kombinasjon av symmetriske algoritmer og to-nøkkelsystemer, ofte med to-nøkkelsystemet som et “grensesnitt” mot brukerne.
Da viser det seg at den største utfordingen i et slikt system ikke er å få overført (offentlige) nøkler til personer som vil sende meldinger til en, men derimot at avsenderen skal være sikker på at nøkkelen tilhører den rette mottageren. En offentlig nøkkel “tilhører” den personen som har denne offentlige nøkkelens hemmelige motpart. Men hvordan kan man egentlig vite hvem som eier en offentlig nøkkel? I en praktisk implementasjon av et system kan offentlige nøkler lagres i en database og hentes fra en Web-side og overføres via internett. Hvordan kan man da sikre seg at databasen ikke er endret av uvedkomne og fremmede nøkler lagt inn isteden for de opprinnelige ?
Svaret på disse spørsmålene er ofte sertifiserting av nøklene. I PGP som ble omtalt i forrige utgave av HØIT ble det beskrevet et “nettverk” av pålitlige nøkler og “sertifiseringen” ble gjort ved at man signerte hverandres nøkler. Arne signerer Bentes nøkkel og gir nøkkelen til Carl. Dersom Carl stoler på Arne og Arnes offentlige nøkkel betyr det at han kan stole på Bentes nøkkel også. Mottar han senere nøkkelen til David som er signert av Bente kan han også i en viss grad stole på denne nøkkelen. Og hvis han mottar en nøkkel signert av David kan han stole...eller kan han det ? Med dette systemet er det klart at det er grenser for hvor langt man kan stole på andres signering av nøkler. Det er også veldig problematisk å finne noe “felles punkt” i nettverket av betrodde nøkler dersom man i utgangspunktet befinner seg langt fra hverandre, sosialt og geografisk.

Figur 4. PGP tillitsmodell: A signerer B,C og E’s nøkkel, B signerer C,D og E’s osv. En annen løsning er at man kan bruke bestemte personer eller firmaer som sertifiserer offentlige nøkler. Disse kalles for Certification Authority (CA), eller Sertifiserings Autoritet (SA) på norsk. Disse utsteder sertifikater som en bruker kan identifisere seg med, et slags ID-kort for bruk på internett. Dette sertifikatet består av 3 hoveddeler: 1) informasjon om sertifikatinnehaveren, som f.eks. navn, organisasjonstilhørighet, e-mail-adresse osv. 2) innehaverens offentlige nøkkel 3) et signert sammendrag av de 2 første delene. Signaturen er gitt av en CA med hans hemmelige nøkkel.
Før sertifikatet signeres må alle data bekreftes på en sikker måte. Hvordan dette gjøres kan variere, men i enkleste form kan det gjøres med personlig frammøte og ved vising av legitimasjon. Man må altså bekrefte at opplysningene i sertifikatet er riktige og at sertifikatinnehaveren også har den tilhørende hemmelige nøkkel. Dette systemet kan også forenkles ved å opprette lokale CA. Man kan f.eks. opprette en CA for en bedrift og denne utsteder sertifikater til alle brukerne i bedriften. Selv har bedriftens CA et sertifikat utstedt av en CA høyere opp i hierarkiet, i Norge kan dette f.eks. være UNINETT. To brukere fra to bedrifter med dette oppsettet kan dermed kontrollere hverandres sertifikater i bare to trinn: Arnes har et sertifikat fra BillyBils CA, og BillyBils CA sertifikat er utstedt av f.eks. UNINETT. Et slikt hierarki behøver som regel bare å bestå av noe få nivåer og en kontroll er ganske enkel. I tillegg åpner noen systemer for at en lokal CA kan signere andre lokale CAs sertifikater, slik det vises på figuren mellom organisasjon B og C. Denne signaturen virker igjen som en bekreftelse på sertifikatinnehavernes identitet. Dermed forenkles kontrollen av brukernes sertifikater ytteligere.

Figur 5. Tillitsmodell med et hierarki av CA’er.

Så til neste utfordring: standardisering av sertifikater. Dersom alle brukte samme system for kryptering ville alt vært enkelt og alle kunne bruke hverandres nøkler og kontrollere hverandres sertifikater. Slik er det selvfølgelig ikke. Men det har etterhvert dukket opp en standard som kan se ut å kunne benyttes for de fleste nøkkeltyper og systemer, og denne lyder det poetiske navnet X.509 og man er for tiden kommet til versjon 3. Dette er altså en standard som bl.a. beskriver hvordan et sertifikat skal se ut. Som et eksempel kan vi se på mitt sertifikat utstedt av en test-versjon av en CA ved Høgskolen,

Version:                 2 (X.509v3-1996)
SubjectName:              CN=Trond Lovereide, <Issuer>
IssuerName:               O=Hogskolen i Ostfold, C=NO
SerialNumber:             4 (decimal)
Validity - NotBefore:   Thu Feb 26 09:35:49 1998 (980226083549Z)
             NotAfter:   Fri Feb 26 09:35:49 1999 (990226083549Z)
Public Key Fingerprint:   225C 0F67 9A57 DB5F E16E E959 6E83 FD44
SubjectKey:              Algorithm RSA (OID 1.2.840.113549.1.1.1),NULL
Certificate extensions:
Authority Key Identifier: 376A 9218 F0DC 056C 1190 260E 1264 C5C0 6446 0E9F
Subject Key Identifier:    2D7E 07EA D6E2 04FB 49BA 2051 2F86 52CD 3E19 D40D
Key Usage:                 (CRITICAL) digitalSignature nonRepudiation
                            keyEncipherment dataEncipherment
Subject alternative names: RFC822: trond.lovereide@hiof.no
Subject alternative names: URL: http://www.hiof.no/~trondl
Basic Constraints:              NOT allowed to act as a CA !
Signature:              Algorithm md5WithRsaEncryption (OID 1.2.840.113549.1.1.4), NULL
Certificate Fingerprint: 50:C3:C0:16:85:B9:D9:98:D4:92:81:47:E0:9D:ED:84

Så er det opp til brukerprogrammet å teste sertifikatets signatur og få bekreftet eierens identitet. Foreløbig kan ikke alle programmer lese slike sertifikater, men Netscape [10] og Microsoft Explorer [5] gjør det ihvertfall, og det er vel en indikasjon på at dette kan bli en utbredt standard.
Hvordan få laget seg et nøkkelpar og et sertifikat.
Det ser altså ut til at systemer med to nøkler og et tilhørende X.509-sertifikat kan bli en utbredt standard. Og dermed kan det være interessant å skaffe seg dette. Jeg vil her gå gjennom hvordan man kan benytte UNINETTs sertifiseringstjeneste for å lage seg et testsertifikat til Netscape.
Du må ha Netscape Communicator, minst versjon 4.0, og for å installere sertifikatene må du bruke Netscape Navigator til de følgende trinnene. Senere kan man få et mer varig sertifikat enten fra UNINETT eller fra en annen CA. Det finnes også en CA for PGP-nøkler ved UNINETT. Denne vil jeg ikke si noe mer om, men henviser bare til websiden [4].
Som tidligere nevnt kan en CA både sertifisere enkeltbrukere direkte og lokale CA for enkeltbedrifter. Rutinene er omtrent like, men jeg vil bare ta for meg sertifisering av brukere uten rett til videre sertifisering.
Henter man frem web-siden til “Trustfactory” [7] for utsteding av sertifikater ser den ut som vist i figur 6.
Som man kan lese av denne siden utstedes kun midlertidige sertifikater til test-formål, med varighet på 30 dager. Sertifikater utstedes også foreløbig bare til bruk på Netscape og Microsoft browsere. Senere vil det også utstedes sertifikater til S/MIME og PEM, begge disse er standarder for kryptering av e-mail.
Etter å ha valgt browser, dvs. Netscape, blir vi bedt om å gi endel opplysninger om oss som skal med i sertifikatet. Siden dette bare er et testsertifikat vil ikke opplysningene vi gir bli kontrollert, i et permanent sertifikat må vi gå gjennom en prosedyre for at sertifikatutstederen skal sikre seg at jeg er den personen jeg sier jeg er. Etter noen flere klikk på “OK” for å sikre at de gitte opplysningene er riktig skrevet, får du sertifikatet lastet over til deg og installert i browseren. Deretter bør du laste ned sertifikatet til UNINETT slik at ditt og andres sertifikat kan verifiseres.
Hvis du nå går til menyen “Security” og velger “Certificates, yours” ser du at sertifikatet ditt er lagt inn. Hvis du går inn på “Security” og “Signers” ser du hvilke sertifikater som allerede ligger i Netscape. Disse er lagt inn i programmet og distribueres med dette. På den måten kan man sikre seg at den eller de CA som skal befinne seg på toppen av hierarkiet ikke er tuklet med. Ser man nøyere etter i denne listen ser man at UNINETT sitt er der fordi du har lagt det inn, det er ikke med opprinnelig. Dersom man gir beskjed om å kontrollere deres sertifikat med “verify” blir ikke sertifikatets identitet bekreftet. Det er fordi sertifikatet er signert av ICE-TEL som heller ikke finnes i Netscapes browser opprinnelig. Organisasjonen ICE-TEL er et EU-prosjekt som er den øverste sertifiserings-autoriteten i Europa. Deres sertifikat kan fås via deres webside [6]. Gå til “X.509v3 infrastructure” (i menyen i venstre ramme), deretter til “The Self-Signed Public Root Key Certificate” og velg “download as pure ASN.1.DER”. Dette sertifikatet vil dermed bli lagt til i sertifikatbasen til browseren og kan brukes til å kontrollere andre sertifikater.
Etter at du har lastet inn dette sertifikatet vil altså ditt sertifikat være signert av UNINETT som igjen er signert av ICE-TEL og du kan utføre en kontroll. Alle som har ICE-TELs og UNINETTs sertifikater kan også kontrollere ditt sertifikat og kan stole på at du er den rette eieren.

Netscape, SSL og https

Nå er vi klare til å gjøre noen tester med sikker overføring av websider.
For å kryptere websider fra server og data fra en browser bruker Netscape en protokoll som kalles Secure Socket Layer (SSL). Dette er en protokoll som ligger mellom protokollen til brukerprogrammet (f.eks. HTTP) og overføringsprotokollen (dvs. TCP/IP). Etter at kontakt er opprettet mellom serveren og browseren via en “handshake”-prosess vil all overføring til og fra serveren bli kryptert. I denne handshake-prosessen sender først serveren sitt sertifikat til browseren og dersom brukeren av browseren også har et sertifikat sendes dette til serveren. Deretter lager browseren et sett med nøkler som krypteres med serverens offentlige nøkkel og sendes til serveren. Disse nye nøklene brukes så til å kryptere all overføring med en symmetrisk algoritme. En kryptert overføring krever altså IKKE at du har et sertifikat, men det kreves at serveren har det, og to-nøkkelalgoritmen brukes bare til å overføre et sett med nøkler som skal brukes i en symmetrisk algoritme.
For å starte en overføring med en server som bruker SSL skriver man bare https://... isteden for http://... i URL’en (Prøv f.eks. https:// www.olc.no eller https://www.amazon.com).
Dersom serveren ikke kan håndtere kryptert overføring vil du ikke få svar, i motsatt fall vil websiden komme fram som før. Som en ytteligere indikasjon på at websiden er kryptert vil ikonet for “security” endres fra en åpen lås til en lukket lås. Trykker du på denne knappen får du informasjon om at websiden har vært kryptert og om serverens sertifikat.

Figur 7. Indikator på en ukryptert webside.

Figur 8. Indikator på en kryptert webside.

Det betyr at vi som brukere ikke behøver å ha et sertifikat for å kunne foreta en sikker overføring av data til en server. Det er nok at serveren og browseren kan håndtere SSL-kommunikasjon og at serveren har et sertifikat. Din sikkerhet når du fyller ut “forms” og sender data til en server ivaretas altså av at de som driver serveren har tatt seg bryet med å skaffe seg et sertifikat og bruker en secure server.
Dersom du har et sertifikat kunne dette brukes til å gi en sikker identifikasjon av deg til serveren, men dette er ikke implementert i Netscape ennå. Det betyr altså at ditt sertifikat ikke brukes, men spesifikasjonen av SSL (v3.0) åpner for at det kan brukes, så det vil sikkert komme i senere utgave av Netscape servere og browsere.

Sikker e-mail med Netscape messenger

Bruker vi derimot Netscape Messenger til e-mail kan vi få brukt det nye sertifikatet vårt. Her brukes ikke SSL for å kryptere meldingene, bl.a. fordi det ville gi problemer for mottagere med e-mail-program uten SSL. Her benyttes isteden en standard som kalles S/MIME for Secure MIME. Dette er bare en variant av MIME som allerede støttes av mange e-mail-program, se f.eks. [8] for en mer detaljert beskrivelse av standarden.
Når du sender e-mail vil teksten krypteres med mottagerens offentlige nøkkel fra hans sertifikat. Deretter gjøres meldingen om til en MIME-melding med noen tillegg og dette sendes til mottageren. Mottageren dekoder MIME-meldingen først og deretter dekrypterer dette med sin hemmelige nøkkel. Helt tilsvarende kan man også bruke sin egen hemmelige nøkkel og signere meldingen. Eller gjøre begge deler. Alt dette er altså med i standarden S/MIME som etterhvert kan håndteres av mange e-mail-program. Ved å benytte MIME-standarden som utgangspunkt oppnår man også at man kan benytte alle de eksisterende protokoller for e-mail (dvs. SMTP, POP osv) uten noen endringer.
For å kunne kryptere en melding til en annen person må man altså ha hans sertifikat. Nå finnes det noen databaser som tar vare på slike sertifikater og Netscape selger også en “directory server” som kan administrere brukere og sertifikater. Sertifikater fra disse databasene kan finnes ved å trykke på ”Security” og deretter på “get certificate”. Hvis sertifikatet du vil bruke ikke finnes der kan du be mottageren om å sende det via e-mail. Dette sertifikatet legges så automatisk i browserens “mappe” med sertifikater og kan brukes til å kryptere e-mail til eieren av sertifikatet.
Når du har installert ditt eget og mottagerens sertifikater kan du skrive meldingen. Så kan du velge “opsjoner til medlingen” (nederst i adressefeltet, under vedlegg) og velge om du vil signere, kryptere eller begge deler.

Figur 9. Opsjoner til e-mail: signert og kryptert.

Ganske likt Navigator vil “security”-knappen endre utseende når du velger kryptert og/eller signert.

Figur 10. Signert e-mail, med og uten kryptering.

Her indikerer altså “merkelappen “ på låsen at meldingen er signert.
Alt dette her ser kanskje ut til å være komplisert og “koste mer enn det smaker”. Men faktisk er det veldig lett å bruke når man først har fått seg et sertifikat, hovedsaklig fordi ting begynner å følge standarder.
Det aller første skrittet kan f.eks være å skaffe seg et testsertifikat og se at det ikke er så vanskelig å bruke. For å skaffe deg et varig sertifikat bør du kontakte UNINETT på deres webside [3], eller evt. vurdere om din bedrift eller organisajon bør opprette en egen CA. I første omgang, og til intern bruk, behøver ikke denne lokale CA være sertifisert av noen CA høyere opp i hierarkiet.

Referanser

[1] HØIT nr 2-97, Papirversjon:   ISSN 0805-6692
[2] UNINETTs innføring i kryptografi, http://www.uninett.no/pca/html/innfoering.html
[3] UNINETT http://www.uninett.no/pca/index.html
[4]|UNINETTs PGP-PCA http://www.uninett.no/pca/html/pgp.html
[5] Microsoft explorer http://www.microsoft.com/ie/
[6] ICE-TEL http://www.darmstadt.gmd.de/ice-tel/
[7] UNINETT/ NRs webside for utsteding av sertifikater: http://www.nr.no/~oddegil/ice-tel/clients.htm
[8] RSA-S/MIME http://www.rsa.com/smime/
[9] Internet cryptography, Richard E. Smith, ISBN 0-201-92480-3
[10] Netscape Communicator http://cgi.netscape.com/cgi-bin/upgrade.cgi

HØit Nr. 1-98