369 total views,  2 views today

I denne artikkelen vil jeg skrive noe om begrepet autentisering. Dette har jeg undervist en del om, og erfarer at det er et tema som mange synes er vanskelig. Og det er litt omfattende, så vi skal diskutere to ulike aspekter ved begrepet:

• Tillit: Hvilke garantier har du når noen har autentisert seg overfor deg?
• Protokoller: Hvordan skal en autentiseringsoperasjon være utformet for at slike garantier kan gis?

(c) Anders Fongen, 2023

Hva betyr ordet?

“Autentisering” betyr å gjøre deg trygg på at du kjenner identiteten til en du samhandler med. La oss starte med en litt overfladisk beskrivelse av prosessen:

1. Du skal logge deg inn på Ebay.com, og skriver inn ditt brukernavn og passord.
2. Tjenermaskinen hos Ebay.com sjekker at det er dette passordet som er registrert med det brukernavnet, og godkjenner innloggingen. 
3. De påfølgende handlingene i Ebay legger til grunn at det er din person som utfører handlingene, og du kan gjøres ansvarlig for svindel og misbruk gjennom rettsapparatet.

Ebays formodning i punkt 3 er et uttrykk for tillit til at en del forutsetninger er oppfylt:

• At brukernavnet som benyttes faktisk er knyttet til din person
• At du har holdt passordet hemmelig og ikke fortalt det til noen
• At du ikke har skadevare på maskinen din som snapper opp passordet og misbruker Ebay-kontoen din
• At det ikke er praktisk mulig å modifisere eller gjenbruke meldingene som overføres på en slik måte at din konto kan misbrukes

Autentisering har også en annen type anvendelse enn pålogging til en nett-tjeneste: Nemlig å produsere et bevis for hvem som har skrevet et stykke tekst, en lydfil, et bilde o.l., altså alt som sendes som en melding og lagres som en fil. Da skal det være mulig å identifisere opphavet for dataene også lenge etter mottaket, og etter en tids lagring. For å få til en slik autentisering bruker vi noe av de samme teknikkene, men det oppstår også noen nye problemstillinger som vi ikke får plass til å diskutere i denne artikkelen.

Tillitskjede

Dette var en ganske lang liste med forutsetninger! Den viser at tilliten til en autentiseringsoperasjon beror på tilliten til et antall ledd i en tillitskjede (trust chain), og dersom ett av leddene svikter, mister man straks tilliten til sluttresltatet.

Skal vi snakke grundig om autentisering kommer vi altså ikke utenom denne tillitskjeden hvor leddene er både av teknologisk og administrativ art. Siden den bloggen du nå leser i er mest interessert i teknologi, vil vi kun omtale de administrative tiltakene i kort form. 

Hva skiller deg fra alle andre?

En kan autentisere seg overfor en motpart ved å demonstrere at man innehar en viss type informasjon som ingen andre har. På engelsk kalles dette proof of possession.

Det vanligste er å demonstrere kjennskapet til et passord, altså noe man vet. Man kan også demonstrere noe man har, f.eks. en mobiltelefon, eller noe man er, f.eks. et fingeravtrykk. Selvfølgelig kan dette kombineres, slik vi gjør hver dag i såkalt to-faktor innlogging: En må demonstrere et passord og bevise at man besitter en bestemt mobiltelefon  (egentlig et SIM-kort) ved å skrive inn en kode som sendes som tekstmelding til denne.

Med demonstrere mener vi ikke overføre! Vi vil ikke risikere at en inntrenger som avlytter en forbindelse skal få kjennskap til den aktuelle informasjonen. Vi vil også hindre en inntrenger å spille av en tidligere overført informasjon (kalt replay-angrep). Mer om dette siden.

Demonstrere betyr altså bevise at man innehar, men det må skje på en måte som hindrer avlytting, fabrikasjon (forfalskning) og avspilling. Disse tre begrepene skal vi vise eksempler på etter hvert.

Kopling mellom identifikator og entitet

Når jeg autentiserer meg over en motpart vil jeg oppgi en identifikator, f.eks. e-post adressen min, og leverer så proof of possession for å vise at jeg faktisk “eier” denne identifikatoren. Vi forutsetter altså at det alltid er en person som eier identifikatoren.

Altså: jeg (personen) kalles en entitet, og jeg kan representeres av en rekke identifikatorer. Dette kan være unike identifikatorer, slik som mitt personnummer eller min e-post adresse. En identifikator kan også være flertydig, som et personnavn ofte er. En unik identifikator kan settes sammen av flertydige identifikatorer, f.eks. navn og bostedsadresse.

Koplingen til en entitet er viktig fordi det er personen som må kunne holdes ansvarlig ved misbruk eller feil bruk som er knyttet til identifikatoren. Derfor er hva jeg er av interesse, fordi mitt fingeravtrykk eller andre biometriske data fra meg ikke kan stjeles (her gjelder det dog noen forbehold). Teknologiske løsninger for å kople identifikator med entitet blir det fortsatt forsket på, men for situasjonen i dag vil denne koplingen i hovedsak være basert på administrative tiltak.

Eksempler på autentiseringsprotokoller

La oss nå ta forutsetningene som nettopp er gjennomgått og konstruere noen autentiseringsprotokoller, alså regler for utveksling av meldinger gjennom kommunikasjonsnettet for å gjennomføre en autentiseringsoperasjon. De fleste av disse protokollene er egnet for diskusjonsformål, men er ubrukelige i praksis.

Protokollene blir vist på figurer som kalles interaksjonsdiagrammer. De vertikale linjene er tidsakser, og de vertikale linjene viser hvordan meldinger utveksles mellom partene Arne og Berit, representert ved firkantene på figurene. Svarte linjer indikerer meldinger som inngår i autentiseringsoperasjonen, røde linjer representerer påfølgende meldinger knyttet til selve applikasjonen.

a. Sende kun identifikator

I dette tilfellet sender Arne kun en identifikator, som blir uten videre godtatt av Berit. Arne beviser intet eierskap til identifikatoren (med f.eks. et passord) og kan sende hvilken som helst identifikator med samme resultat. Denne protokollen oppfyller ikke kravene vi listet opp om å demonstrere “proof of possession”, og er derfor ubrukelig!

b. Sender identifikator og passord

I dette tilfellet vil Arne demonstrere sitt kjennskap til et passord, som er knyttet til brukerkontoen og lagret i tjeneren. Problemet her at dette ikke skjer på en måte som er sikret mot avlytting, fabrikasjon og avspilling. En inntrenger som lytter på forbindelsen (en antagelse vi alltid må gjøre) vil i dette tilfellet kunne avlese passordet idet det blir overført, og siden bruke det for å logge seg inn på Arnes konto. Protokollen oppfyller ikke kravet til sikkerhet mot avlytting, og er derfor ubrukelig.

c. Sender identifikator og hashet passord

La meg først forklare hva en hash-funksjon er: Den lager et slags slags “fingeravtrykk” av en datafil eller en melding. Fingeravtrykket har en fast lengde uavhengig av størrelsen på meldingen. Om vi ønsker å sammenligne innholdet av to meldinger eller datafiler, kan vi nøye oss med å sammenligne deres hash-verdier. En viktig egenskap ved en hash-funksjon er at den ikke kan reverseres. Ut fra en hash-verdi er det ikke mulig å rekonstruere den opprinnelige meldingen. På en Linux-maskin kan hashalgoritmen sha1 demonstreres på denne måten:  

anders@penguin:~$ echo ‘asdasdasd’ | sha1sum
09a9202377d81198d409391ca54376d9c3eaadf2  –

anders@penguin:~$ echo ‘asdasdase’ | sha1sum
a7d61d3b95e2f3253d4e6f3f495d0bf98398c568  –

Vi ser her at disse to tegnstrengene har bare én bit forskjell (i siste bokstav, ‘d’ og ‘e’ adskilles med kun en bit) gir vidt forskjellige hash-verdier.  Med disse egenskapene er en hash-funksjon godt egnet for å overføre et passord.

Protokollen er vist på figuren nedenfor.

I dette tilfellete vil Arne sende sitt brukernavn og hash-verdien av sitt passord, kalkulert med f.eks. algoritmen sha1. Berit kjenner Arne’s passord og kan kalkulere hash-verdien og sammenligne med den mottatte verdien. Sjansen for at et annet passord har samme hashverdi er ufattelig liten. 

Med denne protokollen er det altså ikke mulig for en som avlytter forbindelsen mellom Arne og Berit å avlese Arnes passord. Men protokollen har en stor svakhet, den er utsatt for såkalt replay attack, som jeg her kaller for avspilling. En inntrenger kan lagre hva Arne sender og siden spille dette av i en ny forbindelse til Berit, og dermed utrettmessig få adgang til Arnes brukerkonto. Denne svakheten oppstår fordi alle autentiseringsoperasjoner fra Arne er likt utformet. Så neste versjon av protokollen vil sørge for at påfølgende autentiseringsmeldinger fra Arne får ulikt innhold.

d. Blander en nonce med passordet

På figuren over ser vi at Arnes første melding presenteres hans brukernavn, og Berit svarer med et slags tilfeldig tall, kalt nonce. En nonce (“number once”) er en tallverdi som aldri mer skal brukes, og som garanterer at to like noncer aldri vil deles ut. I praksis kan en nonce være et tilfeldig stort tall, som med svært liten sannsynlighet vil opptre igjen.

Arne kombinerer så sitt passord med nonce-verdien og kalkulerer hashverdien av resultatet, og sender den til Berit. Berit, på sin side, gjør den samme kalkylen (Berit må derfor kjenne passordet i klartekst) og sammenligner med det som Arne sender.

En slik protokoll oppfyller de kravene vi stilte opp tidligere i artikkelen, og lar Arne autentisere seg trygt over Berit. 

Vi ønsker i tillegg en løsning som binder autentiseringen til den påfølgende meldingsutvekslingen slik at det ikke er mulig for en inntrenger å “smette” inn eller endre meldinger etter at autentiseringsoperasjonen er fulllført. Vi kan løse dette med bruk av hash-funksjoner eller kryptering, men da må Arne og Berit være i stand til å utveksle en felles krypteringsnøkkel under autentiseringen som ikke kan avlyttes av en inntrenger. Det blir målet for den neste versjonen av autentiseringsprotokollen.

Litt om asymmetrisk kryptering

Vi tar et lite sidesprang nå for å forklare begrepet asymmetrisk kryptering. Dersom du allerede har kjennskap til dette feltet kan du hoppe over denne teksten.

Mens tradisjonell (symmetrisk) kryptering baserer seg på at både sender/kryptering og mottaker/dekryptering benytter samme krypteringsnøkkel, vil asymmetrisk kryptering bruke ulike nøkler for kryptering og dekryptering. Vi snakker derfor om et nøkkelpar for bruk i slike operasjoner, og det er da vanlig at en entitet (representert ved en identifikator) besitter et slikt par av nøkler, betegnet K⁺ (kalt offentlig nøkkel) og K^– (kalt privat nøkkel). De to nøklene er ulike, men ikke uavhengige. Den offentlige nøkkelen kan være kjent for alle, mens den private nøkkelen er kjent kun for eieren. Kryptering (vist om en funksjon E) og dekryptering (funksjonen D) bruker nøklene på følgende måte. P betegner data i klartekst, C betegner krypterte data:

Kryptering: C = E(K_A⁺, P)
Dekryptering: P = D(K_A^–,C)

Ut fra disse reglene fremgår det at alle kan lage kryptotekst med Arnes offentlige nøkkel, men kun Arne kan dekryptere disse dataene. Derfor kan alle som vil, kryptere data som bare Arne kan lese. Denne egenskapen skal utnyttes i neste versjon av autentiseringsprotokollen.

e. Demonstrerer besittelse av privat nøkkel

I denne versjonen vil Arne benytte sitt nøkkelpar for asymmetrisk kryptering for å autentisere seg. I tillegg ønsker vi at partene skal utveksle en krypteringsnøkkel for å beskytte den påfølgende informasjonsflyten mellom dem. Denne nøkkelen må selvfølgelig overføres på en måte som beskytter mot avlytting fra en inntrenger. 

Arne starter med å presentere sitt nøkkelsertifikat for Berit. Nøkkelsertifikatet er et digitalt dokument som inneholder Arnes identifikator og hans offentlige nøkkel. Når Berit mottar dette vet hun hvem som ber å bli autentisert, og dennes offentlige nøkkel. Berit velger nå en tilfeldig verdi som en midlertidig symmetrisk nøkkel kalt K_secret, som hun krypterer med Arnes offentlig nøkkel, og sender dette tilbake til Arne.

For at Arne nå skal kunne dekryptere denne meldingen må han besitte Arnes private nøkkel. Dermed får han bruke K_secret til å kryptere og dekryptere de påfølgende meldingene. Det at Arne klarer å delta i denne meldingsutvekslingen er dermed en proof of possession av hans private nøkkel, som bare han har kjennskap til.

Nå har vi klart å lage en fungerende autentiseringsprotokoll som også beskytter den meldingsutvekslingen som følger etter autentiseringsoperasjonen. Men det er fortsatt noe vi ønsker i en autentiseringsprotokoll og det er gjensidighet.

Med gjensidig (mutual) autentisering mener vi at begge parter autentiserer seg overfor motparten. Dette er en viktig egenskap fordi om Arne blir lurt til å snakke med en som utgir seg for å være Berit (noe ingen av de hittil viste autentiseringsprotokollene kan forhindre) kan Arne bli lurt og svindlet på mange slags måter i den påfølgende meldingsutvekslingen. 

f. Gjensidig autentisering

I denne versjonen av autentiseringsprotokollen bruker vi også prinsippet om asymmetrisk kryptering i likhet med den forrige versjonen, men her ser vi at nøkkelsertifikatene utveksles i begge retninger, og det utveksles to midlertidige nøkler, som brukes til å kryptere påfølgende meldinger i hver sin retning. Prinsippet er altså det samme som i versjon (e), og brukes i begge retninger.

Legg merke til at vanlig passordbasert autentisering ikke er praktisk ved gjensidig autentisering. Om Berit er en tjeneste som benyttes av mange, er det ikke fornuftig å la mange kunder som, i likhet med Arne, må kjenne Berits passord.

Merk også at denne autentiseringsalgoritmen kan utformes på flere forskjellige måter: En av dem er å benytte digital signatur, en annen vil være å bruke samme midlertidige nøkkel i begge retninger. Den foreslåtte metoden er bare bare én av flere mulige. 

“Denial of service” angrep

Forkortet DoS, på norsk kalt tjenestenektangrep, betegner et angrep som har som mål å hindre andres bruk av tjenesten. I protokollutgave (d) og (f) vil Berit motta en innledende forspørsel fra Arne, respondere på denne mens den venter på neste melding fra Arne. Dersom Arne er en ondsinnet part kan han la være og sende denne neste meldingen, og la Berit vente i det uendelige mens hun fortsatt vil måtte huske at en autentiseringsoperasjon med Arne er i gang. Dersom en angriper sender en million slike innledende meldinger, kan minnet til Berit fylles opp slik at ingen flere autentiseringsoperasjoner kan gjennomføres, og de lovlige brukerne av tjenesten ikke slipper til. Dette kan derfor utgjøre et tjenestenektangrep, og en som skriver koden for Berit må f.eks. sette tidsgrenser for hvor lenge hun vil vente på neste melding fra Arne, utover denne tidsgrensen kan autentiseringsoperasjonen avbrytes.

Oppsummering

I denne artikkelen har vi gått gjennom prinsippene for autentiseringsoperasjonene, og vist en del eksempler på autentiseringsprotokoller, både noen ubrukelige og noen som virker. 

De beste autentiseringsprotokollene som vi har vist, (d), (e) og (f), kan garantere den som ønsker å autentisere seg har demonstrert eierskapet av noe han vet. I dette tilfellet er det enten et passord eller en privat nøkkel. Det foreligger derimot ingen garanti at dette er den personen (entiteten) som representeres av identifikatoren. En slik garanti, kalt establishment of identity, er svært vanskelig å gi, selv med avanserte biometriske teknikker som en del av autentiseringsprotokollen. Dersom passordet eller den private nøkkelen lekkes til andre er det som regel mulig for dem å utgi seg for den personen passordet hører til.

Takeaway fra denne artikkelen

1. Autentisering er proof of possession av noe du vet, noe du har, eller noe du vet.
2. Overføres på en måte som er sikret mot avlytting, forfalskning eller avspilling.