* 4 *

Legitimasjon og autentisering

Ukens faktum

Etter den andre verdens krigen, ble det nå berømte paret Julius og Ethel Rosenberg tiltalt for spionasje for Sovjetunionen i 1953. De hadde improvisert et passordsystem: en dessertemballasje ble revet i to og en del ble gitt til en kontaktperson som de senere ville måtte idenifisere. Den komplekse formen var umulig å forfalske. Kroppene våre bruker en lignende metode for å identifisere molykyler i immunsystemet og luktesansen. Uten å matche unike egenskaper er det umulig å verifisere identitet.

Kapittel 2 Gollmann, kapittel 9 Stallings
For å kunne implementere de grunnleggende Orange Book sikkerhetsmekanismene, trenger vi å kunne følge identitetene til brukere som ber om systemressurser. Autentisering betyr å finne ut om noe er autentisk. Vanligvis mener vi en persons identitet. Det er to grunner til at vi ønsker å identifisere noen:

Login: brukernavn og passord

Når vi logger inn på et sikkert operativsystem blir vi spurt om brukernavn og passord. Brukernavn påstår vår identitet og passordet brekrefter påstanden. Hvis autentiseringen lykkes blir vi innvilget tilgang til systemet, og alle våre aktiviter foregår da innen den identitens rammer. På Unix-aktige systemer oppsummeres identiteten ved et globalt unikt tall eller user-ID (UID). På Windows systemer brukes et security ID (SID) som er unik kun på den lokale maskinen.

I distribuerte systemer, må vi spore identiteter mellom maskiner også. Det betyr at vi enten må

Unix og Windows håndterer disse sakene ulikt. Unix systemer kan konfigureres til å bruke alle løsningstypene. Windows bruker en implisitt tillitsmodell (trust model) som er basert på en global autentisering for et helt domene. Når en bruker gis tilgang til et domene får han/hun rettigheter som tilsvarer domenet. Denne identiten er basert på brukernavnet, ikke SIDen, da SIDen er forskjellig fra maskin til maskin. I den originale Unix modellen måtte brukere dele et felles brukernavn på andre maskiner dersom de skulle slippe å logge inn pånytt der. Ved å bruke .rhosts filer kunne en bruker erklære tillit til en bruker med samme navn på en fjernmaskin bare ved å skrive maskinen i en liste.

Det er opplagte problemer med passord legitimasjon

Mange brukere velger bare svake passord og disse kan gjettes ved bruk av ren regnekraft.

Denne type login kalles for unilateral (ensidig) autentisering, dvs. det idenitifiserer brukeren overfor systemet. Den bekrefter ikke identiteten til datasystemet overfor brukeren! Dette ville hett bi-lateral (gjensidig) atentisering). Altså, ett problem som kan oppstå er at en inntrenger kunne forfalske innloggingsprosessen til en maskin, og samle opp passord og konto informasjon fra brukerne som prøvde å logge seg inn. Unix prøver ikke å løse dette problemet selv, men NT krever en `secure attention sequence' for å kunne logge inn. Dersom brukeren taster CTRL+ALT+DEL, henvises de direkte til operativsystemet, og ikke til andre programmer som prøver å etterligne OSet.

Hvor mange ganger skal vi måtte taste inn et passord? Trenger vi flere passord til ulike sikkerhetsnivåer? F. eks.

I mange tilfeller holder det med en enkelt login (single sign-on). Når identiteten er bekreftet får brukeren privilegier som gir tilgang til alt som de har lov til å se. Men noen systemer må skilles, da de er helt frakoblet legitimasjonssystemet som brukes for login. WWW er et slikt system.

Biometrics

Det fins mange måter å gi et passord på. For eksempel, biometrics er navnet som brukes for å snakke om det fagfeltet som dreier seg om identifisering av menneske fysiologi og psykologi for å autentisere. Som filmen Gattaca noterte, er det ikke umulig å forfalske biometriske data. Poenget med biometrikker er å komme unna problemene med passordmodellen, men det fins et problem. De har faktisk alle de samme problemene som passord modellen har, pluss et nytt problem: vi kan ikke bytte våre biometriske signaturer dersom de blir stjålet eller forfalsket. Vi kan i miste fall bytte digitale signaturer.

Biometriske scanne-enheter må selv være sikre. Selv om iris-igjenkjenning regnes som nesten umulig å forfalske (i dag) fins det alltid mulighet for at selve scanne-enheten kan mates med stjålet data, fanget opp tidligere. Brukere må derfor være forsiktig med å stikke irisene sine i maksiner de ikke vet så mye om.

Challenge/response protokoller

I challenge/response systemer (også kallt nonce eller number-once metoder), genereres den som autentiserer en tilfeldig en gangs utfordring (spørsmål) som klienten må svare på ved hjelp av en eller annen hemmelig nøkkel. Det enkleste eksemplet på et slikt system er login utfordringen: "Enter password". Utfordringen ved broen i Monty Python filmen The search for the holy grail ville ikke vært et forsvarlig system av to grunner: det er basert på felles kunnskap som hvem som helst kunne kjent til. Det var også mulig å hakke (og kræsje!) autentiserings enheten.

OSI sikkerhets arkitekturen (ISO 7498-2) skjelner mellom origin authentication og entity authentication, dvs hvem som snakker og hvor de snakker fra. ISO/IEC 9798 er en standard som er under utvikling. Den publiseres i flere dokumenter. Vi skal se nærmere på noen av ideene beskrevet der.

Vi definerer:

Entity/origin authentication kan oppnås bare innen visse tidsrammer. Vanligvis sjekkes dette i begynnelsen av en sesjon mellom klient og server. Når vi slutter å sjekke, er det mulig for noen å lure seg inn eller bytte plass med en autentisert bruker. Dvs at for å sikre en hel samtale over lang tid, må vi bruke en hemmlighet til å kryptere samtalen, som kun de autentiserte partene kan (noe som utveklses/avtales under autentiseringen).

Egenskapene til en autentiseringsprotokoll

La oss snakke litt mer formelt om autentisering via protocol. Vi antar at det fins to parter: A (Alice) og B (Bob), som utveksler et endelig antall beskjeder: 
       |                         |
       |           M1            |
       | --------------------->  |
       |           M2            |
    A  | <--------------------   |  B
       |           M3            |
       | --------------------->  |
       |           M4            |
       | <--------------------   |
       |                         |.
A begynner protokollen ved å sende en beskjed til B, M1. B svarer med M2 osv. Vi antar at beskjed N+1 ikke sendes før beskjed N er oppfattet.

Under eller etter utvekslingen av protokollen må vi bli sikre på følgende punkter:

Det er ikke alltid mulig å tilfredstille alle disse kravene inntil hele utvekslingen er over. Integriteten til beskjedene kan sjekkes på flere måter (hvordan vet vi at ingen har endret beskjeden underveis) Vi må også sjekke av beskjeden er fersk (ikke et replay) av en tidligere beskjed som ble avlyttet. Her fins det to metoder: Obs at tidsstempler er avhengige av at systemklokkene er synkroniserte for begge parter. Dette impliserer en avhengighet. Siden ingen overførsel er momentant, må vi tillate visse akseptable tidsrammer hvor svar til utfordringer godkjennes. Dette betyr at det fins en window of opportunity eller mulighet for å utnytte protokollen. I nonce/challenge metoden, sendes en random verdi i den første beskjeden som må sendes i svaret til beskjeden, slik at begge parter er enige om en engangs sesjon-nøkkel. F. eks. verdien kunne brukes for å kryptere sambandet slik at gamle beskjeder ville tolkes som garbage. Det er opp til A å passe på at verdien er ny og ikke forutsigbar. Forutsigbare sekvensangrep har blitt brukt mot TCP protokollen, for eksempel.

Eksempler

Betrakt den følgende beskjeden. En enkelt beskjed som sendes fra A til B. Beskjeden innholder tiden t og en passordnøkkel som bare A og B kjenner til (Kab). 
EKSEMPEL 1:

       |                         |
       |      M1(t,Kab)          |
  A    | --------------------->  |  B
       |                         |
B kan verifisere As identitet, men A kan ikke identifisere Bs identitet. B vet at A er A fordi beskjeden er kryptert med Kab som bare A kan. B vet at beskjeden er fersk fordi tiden kan sjekkes. A kan ikke være sikker på Bs identitet forsi B beskrefter aldri sin identitet på noe vis. 
EKSEMPEL 2:

       |                         |
       |      M1(t1,Kab,S)       |
  A    | --------------------->  |  B
       |      M2(t2,Kab,S)       |
       | <---------------------  |
       |                         |
Det andre eksemplet ligner på det første men A sender nå en utfordring streng S for sesjonen. B svarer nå, og bruker også kyptertings nøkkelen Kab. A kan nå finne ut at, siden B mottok beskjed M1 og svarte med M2 riktig kryptert, at det faktisk må være B, da kun B kjenner til Kab. Dette er gjensidig autentisering. Det krever toveis kommunikasjon. Begge parter vet at sesjonen ikke er et replay fordi tiden sendes. Dersom sesjonsnøkkelen også er unik, er tidsstemplene overflødige.

Nøkler

Sikkerheten rundt nøklene kan ikke understrekes nok her. Vi stoler implisitt på kryptering som en bekreftelse på identitet. Dette betyr at vi stoler på systemene hvor nøklene ligger. Protokoller som er basert på en felles hemmelighet ab trenger et seperat nøkkelpar for hver tillitsgruppe/sone. En mulighet er å bruke en felles nøkkel for alle maskiner, og ha maskinene identifisere seg selv som en del av protokollen: 
  M(t,K,hostname,S)
Dette antar at alle maskinene stoler på hverandre, Et alternativ er å bruke PGP-stil RSA nøkler. Dette krever bare en måte å distribuere nøklene på som kan stoles på. Dette gjøres often gjennom en tredje part, eller Trusted Third Party (TTP).

Needham-Schroeder protocol

One protocol for establishing identity was devised in 1978 by R. Needham and M. Schroeder. It uses the idea of a trusted third party and private keys, or password-based encryption to pass messages.

Suppose Alice wants to send a message to Bob. Both Alice and Bob have already registered a secret key, protected by a password, with a trusted key server (Sam). They assume that everyone else in their local domain has done the same. The trick is to establish an encryption key (K) from A to B, given only the keys they have between themselves and Sam, without an attacker being able to understand the messages. Essentially Alice asks Sam to encrypt a message to Bob for her, without giving away Bob's key. 

1. A -> S : A,B,Na
2. S -> A : {Na,B,Kab,{Kab}Kbs}Kas
3. A -> B : {Kab}Kbs
4. B -> A : {Nb}Kab
5. A -> B : {Nb-1}Kab
Recall that the curly braces mean a message which is encrypted, using the key subscripted. In words, this says the following:
  1. Alice say to Sam: "I am Alice, I want to talk to Bob and I'm giving you a random nonce Na."
  2. Sam replies, quoting her nonce to show that he is a good beauracrat, confirms that the message is about a key with Bob, provides a key for encrypting messages between Alice and Bob. He also provides a message for Bob, already encrypted with the secret key that Bob and Sam share (Kbs). This message contains Alice's name and the session key (Kab) for talking to Alice privately. All of this is encrypted with the private key that Alice and Sam share (Kas).
  3. Alice simply sends the message which Sam encrypted to Bob. This is already encrypted.
  4. Bob decrypts the message and replies using the session key (Kab) with a nonce of his own to make sure that Alice is awake, i.e. that this is not a replay.
  5. Alice responds that she received the nonce.
Alice and Bob are now ready to talk, using the key (Kab).

This protocol is the basic for the Kerberos system, which is used in many Unix and Windows 2000 systems. The protocol is still controversial, after 20 years because it is not possible for Bob to tell whether the key (Kab) is fresh. It could also be twenty years old! This is not necessarily a problem, in practice, but in principle this might be exploited by an attacker.

Ukens tanke

Steganography dreier seg om å skule beskjeder inn i andre beskjeder, slik at selve beskjedens eksistens er hemmlig. Nylig har man begynt å skjule beskjeder i bilder...

Back