Kryptoprotokollat, luento 2 (A), 9.2.2009

Autentikointia, ja joukossa
viittauksia luettavana olleeseen artikkeliin [Abadi: Sec. Prot. and their Properties]

Autentikointia

Johdanto

Jos seitistä hakee termillä "authentication protocols", saattoi joskus löytää esim tällaisen luettelon [The Computer Technology Documentation Project]. Mitä siitä voisi sanoa?

Various authentication protocols are listed and described below.

PAP - Password Authentification Protocol is a two way handshake protocol designed for use with PPP. Password Authentication Protocol is a plain text password used on older SLIP systems. It is not secure.
SPAP - Shiva PAP. Only NT RAS server supports this for clients dialing in.
CHAP - Challenge Handshake Authentication Protocol is a three way handshake protocol which is considered more secure than PAP.
MS-CHAP (MD4) - Uses a Microsoft version of RSA message digest 4 challenge and reply protocol. It only works on Microsoft systems and enables data encryption. Selecting this authentification method causes all data to be encrypted.
S/Key - A one time password system, secure against replays. RFC 2289.
EAP - Extensible Authentication Protocol is used between a dial-in client and server to determine what authentication protocol will be used.
DES - Data Encryption Standard for older clients and servers.
RADIUS - Remote Authentication Dial-In User Service used to authenticate users dialing in remotely to servers in a organization's network.
TACACS - Offers authentication, accounting, and authorization. SKID - SKID2 and SKID3 are vulnerable to a man in the middle attack.

Lista on tosin käytännöllinen, mutta kovin yksipuolinen, sillä se liittynee johonkin erityiseen asiayhteyteen. Minkälaiseen? Mitä puuttuu, jos listan haluaisi olevan kattavampi?

(Vastausta: Etäkäyttäjän autentikointiin verkossa ja esillä on protokollan toteutuksia. Puuttuu sellaisia tuttuja kuin IKE, Kerberos, SSH jne. On ylimääräinenkin: DES, joka ei sellaisenaan ole mikään protokolla. Lista oli alunperin muuten aakkosjärjestyksessä.)

J.Guttmanin artikkeli Security Protocol Design via Authentication Tests (2002) luonnostelee SETiä vastaavan ATSPECT-protokollan (Authentication Test-based Secure Protocol for Electronic Commerce Transactions). Artikkeliin palataan suunnittelumenetelmän näkökulmasta B-osassa (pohjalla formaali strand spaces -tekniikka).

Artikkelissa esitetyt suunnittelutavoitteet saavat toimia lähtökohtana päivän autentikointiaiheelle. Niiden lähtökohtana on kolme osapuolta: asiakas, kauppias ja pankki, joista seuraavassa käytetään muuttujia P ja Q:

Confidentiality
All data transmitted in the exchange is to remain secret, and data intended for a pair should not be disclosed to the third participant.
Authentication, I
Each participant P should receive a guarantee that each partner Q has received P's data and Q accepted it.
Non-Repudiation
Each participant P should be able to prove its Authentication, I guarantee to a third party.
Authentication, II
Each participant Q should receive a guarantee that data purportedly from a partner P in fact originated with P, freshly in a recent run of this protocol.

Mitä siis autentikointi tarkoittaa?
Mitä se on mielestäsi tähän asti tarkoittanut?
Millaisia autentikoinnin käsitteitä Abadí määrittelee artikkelissaan?

Vastausta:

... Auth-I voi kuulostaa erityisen oudolta, ellei sen huomaa koskevan Q:ta eikä P:tä.
Varmaankin lähinnä Auth-II:n tapaista, olion (P:n) ja viestin todenmukaisuutta.
Kahta hyvin erilaista sisältöä: voi olla vastuullisuus tai hyvitys ("credit"). Vaikka autentikoinnin protokollissa ei yleensä oteta kantaa sen jälkeen tapahtuvaan pääsynvalvontaan ja siinä välittyviin oikeuksiin, mainittu ero täytyy artikkelin mukaan tehdä, koska jotkin protokollat tarjoavat perusteet vain toiseen näistä sisällöistä.

Tähänastisia määrittelyjä kursiivilla, ensinnä peruskurssilta

(Olion) "Autentikoinnin perusteet" [id=61]:
Autentikointi on vakuuttumista siitä, että jokin
ennestään tunnettu tai muuta kautta tunnettavissa oleva
identiteetti liittyy johonkin olioon

tai ainakin aiemmin myönnettiin tavoitteena olevat oikeudet juuri samalle oliolle.

Olio erottuu muista ja antaa perusteet vakuuttumiselle yhdellä tai useammalla seuraavista:

se on, omistaa tai tietää jotain.
Lisäksi voi vaikuttaa se, missä se on: esimerkkinä
(1) TTY:n internet-osoite oikeuttamassa artikkelitietokantojen käyttöön ja
(2) Unixissa globaali tiedosto /etc/hosts.equiv kertomassa, mistä muualta tulijaa kohdellaan kuin hän olisi paikallisesti autentikoitu samalla tunnuksella, ja käyttäjäkohtainen .rhosts, jossa voidaan tarjota vastaavaa toisennimiselle.

"Haaste-vaste -menetelmä yleisesti"[id=63] Tiedettyyn perustuvaa olion autentikointia.
Vahva autentikointi: hyökkääjän tehtävä on oleellisesti vaikeampi kuin

salasanojen arvaaminen tai

aiemmin kaapatun käyttäminen uudelleen.

Roolit ja tavoite: Todentaja vakuuttuu tunnistautujan autenttisuudesta.

Haasteena on satunnaisluku.
Vaste lasketaan siitä ja tunnistautujalla olevasta tiedosta

symmetrisellä (salaus)algoritmilla

epäsymmetrisllä algoritmilla

kryptotiivisteellä
Jatkokurssilta
"Autentikoinnin protokollista" [id=199]: Vahvempaan tarvitaan kryptoprimitiivejä. Salasanajärjestelmää sinänsä voidaan vahvistaa kryptoprotokollalla, ja hyvä onkin sillä muuten ihmisolio jäisi heikolle puolelle (vrt. salasanan vahvistajat EKE, SPEKE, SRP ja PDM jatkokurssin B-osassa [id=60] ja myöhemmin tällä kurssilla).

Protokollia on erilaisia myös sen mukaan,

montako viestiä niissä tarvitaan,

tapahtuuko samalla molemminpuolinen autentikointi vai

täytyykö sitä varten suorittaa kaksi erillistä protokollaa.

Lisäksi voidaan tarkastella turvallisuutta erilaisten uhkamallien puitteissa. Suorituskyvyn mittana voidaan laskea viestien määrän lisäksi myös

krypto-operaatioita julkisella avaimella;
krypto-operaatioita yksityisellä avaimella (esim. RSA:ssa paljon työläämpää kuin ed.);
tavumäärää, joka salataan tai puretaan symmetrisellä avaimella;
tavumäärää, johon sovelletaan tiivistealgoritmia.
lisäksi voidaan tarkastella minkä verran tilatietoa osapuolet -- varsinkin palvelin -- joutuu pitämään yllä. (Asia liittyy seuraavaan kertaustietoon.)

Tarvitaan vaihtuvaa tietoa, joka estää viestien toistamisella tapahtuvat hyökkäykset.

satunnaisluku, jonka toinen keksii ja toinen palauttaa

aikaleima, jos kellojen ajassa olemiseen voidaan luottaa.

Lisäksi sarjanumero voi käydä.

Jos perustana on symmetrinen tieto, tarvitaan yleensä vähintään kaksi viestiä, olipa pohjalla salaus tai tiivistefunktio. Julkisen avaimen systeemillä voidaan selvitä yhdellä viestillä.
Kohta nähdään useita malleja (ja yhden viestin symmetrinen systeemi).

"Tiedettyyn perustuva autentikointi" [id=66]: Kooste, joka kertaa jaottelun symmetriseen ja epäsymmetriseen tietoon. Symmetrinen on ainakin jossain vaiheessa ollut yhteistä tietoa ja keskeiset kysymykset ovat, minkä verran todentajan täytyy tallentaa sitä ja millä tavoin vakuuttuminen tapahtuu. Epäsymmetriseksi luokiteltiin PKI-systeemin lisäksi hash-iteroitu salasana.

Protokollia

Tarkastellaan (ja kerrataan) nyt autentikoinnin protokollia, ja arvioidaan niitä mukaillen kirjaa Kaufman, Perlman, Speciner: Network Security (luku 11). Kysymyksiä:

millaisen uhkamallin torjuu:
- mitä yleisiä heikkouksia on?
- mitä jos todentaja (palvelin) huijaa tai sen tietokantaan murtaudutaan?
- onko off-line arvaushyökkäys mahdollinen, vai pelkkä on-line?
viestien määrä ja muut suorituskykypiirteet?
miten voidaan samalla luoda istuntoavain?

Olkoon käytettävissä algoritmeja viestille m:

kryptotiiviste H(m)
symmetrinen salausalgoritmi E_avain(m)
merkitään yhteisesti F(avain, m) , jos voidaan käyttää yksisuuntaisesti
kumpaa vain, E:tä tai H:ta, eikä purkua tarvita.
epäsymmetrinen salaus Q:n julkisella avaimella {m}_Q
allekirjoitus Q:n yksityisellä avaimella [m]_Q
satunnaislukugeneraattori + mahdollista redundanssia, tuloksena R, R1, R2, ...
Lisäksi käytettävissä on tuore aikaleima T.

Tavoitteena on aluksi A:n autentikoituminen B:lle, sitten molemminpuolin ja kolmantena vielä istuntoavaimen sopiminen. Tarkastellaan ensin symmetristä, sitten epäsymmetristä ja lopuksi kolmannen osapuolen välittämää tietoa.

Yhteinen tieto: k

Salasana-autentikointi tarkoittaisi k:n lähettämistä selväkielisenä, sillä mitään suojausta ei ole vielä rakennettu. Varsinaisia protokollia (kirjoita nämä auki!):

Toispuolinen autentikointi

A ilmoittautuu eli lähettää B:lle tunnuksensa ja
	saa haasteen R	ja vastaa:	F( k, R )	(S1)
	saa haasteen E_k(R)	ja vastaa:	R	(S2)
	lähettää samalla kertaa:	E_k( T )		(S3)
	lähettää samalla kertaa:	T, H( k, T )		(S4)

Tässä on neljä erilaista protokollaa S1..S4.

Molemminpuolinen autentikointi

(S1):n mukaisesti:
	täysi: viisi viestiä (vain B:n ilmoittautuminen puuttuu)	(S5)
	paranneltu: 4 viestiä, A haastaa samalla kun vastaa	(S6)
	optimoitu: 3 viestiä, kumpikin haastaa jo 1. viestissään	(S7)

(S3):n mukaisesti 2 viestillä, kunhan T muuttuu (roolit erottaen)		(S8)

Istuntoavain

Vaikka k on yhteinen salaisuus, sitä ei kannata käyttää salaus- tai eheysavaimena, jotta erilaisten käyttötarkoitusten turvaominaisuudet eivät sekoittuisi (esim. salausavain "kuluu" nopeammin kuin autentikointiavain). Avainta k riittää modifioida jotenkin ja siinä voi käyttää protokollassa esiintyneitä satunnaislukuja (R). Muunnos pitää tehdä sillä tavoin yksisuuntaisesti ja kertaluonteisesti, että myöhempi istuntoavaimen paljastuminen ei vaarantaisi aikaisempaa eikä myöhempää viestintää. Sama koskee yksipuolisessa autentikoinnissa sitä, että B onkin hyökkääjä.

Istuntoavaimeksi voi laskea esim. seuraavia: E_k+1( R ), E_H(k)( R ), E_k( R+k ), H(k+1, R). Tässä täytyy olla tarkkana, sillä esim. E_k( R+1 ) tai H(k, R+1) eivät käy niissä, missä E_k( R ) tai H(k, R) esiintyy protokollan viestinä ja haaste R näkyy ennen sitä. Hyökkääjä voisi onnistua haastajan roolissa lähettämään R+1:n ja saamaan vasteeksi juuri nämä.

Epäsymmetrinen tieto: osapuolilla autenttiset julkiset avaimensa

Toispuolinen, A autentikoituu B:lle

A ilmoittautuu B:lle
	saa haasteen R	ja vastaa:	[ R ] _A	(P1)
	saa haasteen { R } _A	ja vastaa:	R	(P2)

Tässä on siis kaksi protokollaa P1 ja P2.

Molemminpuolinen

soveltaen (P1):ta (S7):n tapaan	(P3)
soveltaen (P2):ta (S7):n tapaan	(P4)

Istuntoavain

Toispuolinen PKI-autentikointi on arkipäivää SSL:n käytössä. Istuntoavain voidaan luoda Diffie-Hellman -vaihdolla, jossa A allekirjoittaa DH-puolikkaansa. Kun salaus istuntoavaimella on saatu aikaan, osapuoli B voi autentikoitua salasanalla. Jos se onnistuu, A tietää että DH-vaihtokin tapahtui saman B-olion kanssa. Heikompi menettely on lähettää { K }_A, mutta ongelmana on lähinnä vain se, että hyökkääjä voi joskus murtaa osapuolen A ja pystyä silloin purkamaan tallettamansa K:lla salatut viestit.

Molemminpuolisessa autentikoinnissa vahva mekanismi on tehdä autentikointiviestien lomassa Diffie-Hellman -vaihto, jossa DH-puolikkaat allekirjoitetaan. Yksinkertaisempi tapa on vaihtaa viestit { K1 }_A ja { K2 }_B ja laskea avaimeksi K1 XOR K2.

Jos haluttaisiin vielä yksinkertaisempi järjestely, toinen osapuoli P voisi vain lähettää toiselle eli Q:lle viestin tai viestikentän { K } _Q, samaan tapaan kuin toispuolisessa autentikoinnissa. Kun nyt autentikointi oli jo molemminpuolista, ei sitä salauksen alettua varmaankaan enää täydennetä. Tällöin hyökkääjä voi kaapata yhteyden korvaamalla P:n lähettämän viestikentän arvolla { K' } _Q eli omalla K':llaan Q:n julkisella avaimella salattuna. Tämän jälkeen hän voi saada puretuksi P:lle tarkoitettuja viestejä.

Autentikoinnin arviointia mahdollisten hyökkäysten osalta

Yksisuuntaisissa tietenkään B:stä ei synny varmuutta.
Kaikissa pätee:

off-line arvaushyökkäys on mahdollinen, mutta jos k:ssa on tarpeeksi entropiaa (toisin kuin salasanassa) tästä ei ole haittaa (vrt. IKEn off-line-murtaja http://ikecrack.sourceforge.net/)
istunto on mahdollista kaapata, jos jatkossa ei ryhdytä salaamaan autentikointiprotokollaan kytketyllä avaimella.

Off-line -arvaus on (S2):ssa mahdollinen ilman (ehkä vaivalloista) salakuuntelua, jos R:ssä on runsaasti redundanssia. Hyökkääjän tarvitsee vain esittäytyä A:na ja saada B:ltä vastaus. Sama on mahdollista protokollassa (S7) eikä siinä tarvita redundanssia. Korjauksena on (S6). Toisaalta jos R:ssä on riittävästi redundanssia ja aikaleima, (S2):ssa myös B tulee autentikoiduksi!

Aikaleimaprotokollissa (S3) ja (S4) edellytetään kohtuullisen synkronissa olevia kelloja ja luottamusta niihin (säätämiseen tarvittaneen jokin leimoista riippumaton protokolla!). (S3) on kätevä yksinkertaisissa pyyntö-vastaus -autentikoinneissa. Toistohyökkäyksen esto kumpaankin: B muistaa A:n käyttämät aikaleimat niin kauan kuin ne ovat voimassa. Aikaleima selkokielisenä on tarpeen (S4):ssä, jos sallitun aikaeron sisällä on liian hienojakoinen aika-avaruus, eli liian monta kokeiltavaa B:lle.

"Peilaushyökkäys" (S7):ä vastaan: hyökkääjä ottaa A:n roolissa kahdesti yhteyden B:hen ja jälkimmäisellä kerralla lähettää omana haasteenaan saman, jonka itse sai ensimmäisellä kerralla. Korjaus: A ja B eivät laske tarkalleen samaa: eri avain (myös k:n johdannaisena) tai erinäköinen haaste eri suuntiin.

Julkisen avaimen protokollissa (P*) tärkeää on, ettei hyökkääjä saa lypsetyksi asiattomia allekirjoituksia tai salauksen purkuja. Joko avainten täytyy olla vain tiettyyn tarkoitukseen tai niitä käytetään vain tietynlaista muotoa oleviin viesteihin. Näissä protokollissa palvelimen B tietokanta ei ole arkaluonteinen, mutta eheyttä tietenkin pitää varjella. Tuttu hankaluus liikkuvaisen A:n kannalta: missä säilössä B:n julkinen avain olisi, tai edes oma yksityinen avain? Kätevä mahdollisuus: B (tai jokin muu palvelin) tallettaa ne, salattuna A:n salasanasta johdettavalla avaimella; B:n julkinen avain voi yhtä hyvin olla siellä myös A:n allekirjoittamana. Näin tarjoutuu vähemmän mahdollisuuksia A:n salasanan arvaamiseen.

Apuna kolmas osapuoli C

Julkisten avainten varmentajaa edellä jo saatettiin tarvita ja se on tietysti yhdenlainen kolmas osapuoli. Samoin olisi julkisten avainten hakemisto, joka ilman varmenteita kertoisi luotettavalla tavalla eri osapuolten avaimia. Kunkin avainta kyselevän pitäisi tietysti autentikoitua siihen jollain yo. menetelmällä ja sen jälkeen viestien täytyisi olla salattuja. Jos ne olisivat vain allekirjoitettuja, ne vastaisivat jossain määrin tietysti varmennetta. Jätetään tuon asian pohdiskelu ja katsotaan, millaisia rakenteita saadaan aikaan, jos jokaisella on oma symmetrinen salaisuus C:n kanssa.

Mainitunlaista C:tä voitaisiin kutsua avainkeskukseksi. Voidaan luonnostella neljä protokollaa, joilla A ja B voivat luotettavasti sopia yhteisestä symmetrisestä avaimesta C:n avulla.

Jos C toimii avaintenjakelukeskuksena (KDC, D=Distribution) saadaan kaksi mahdollisuutta: C antaa A:n ja B:n omilla avaimilla salatun avaimen joko A:n kautta myös B:lle tai suoraan kummallekin. Jos C toimii avaintenvälityskeskuksena (KTC, T=translation) saadaan vastaavat kaksi mahdollisuutta: C lähettää A:lta saamansa (salatun) avaimen B:lle joko A:n kautta tai suoraan. [HAC:546]

KDC on tavallisempi ja se on tuttu Kerberoksesta (ja tavataan vielä protokollissa Otway-Rees ja Needham-Schroeder). Pohdittavaksi: Voisiko (ja kannattaisiko) tätä yksitasoista symmetristen avainten rakennetta jotenkin yleistää varmennestruktuurien tapaan?

Kun avainten vaihto on nyt tullut esille, autentikoinnin käsitettä voidaan jaotella tarkemmin noudattaen kirjaa Handbook of Applied Cryptography [HAC, s.492]:

autentikointi (authentication)
merkitys riippuu yhteydestä
olion a. (entity a.)
osapuolen identiteetti sekä aktiivisuus (aliveness) tietyllä hetkellä
alkuperän a. (data origin a.)
tiedon lähteen identiteetti
(implisiittinen) avaimen a.
mahdollisesti avaimen jakavan osapuolen identiteetti: siis olio, jolla avain vain voi olla (itsemme lisäksi), on autentikoitu. Saadaan aikaan esim. lähettämällä sille sen julkisella avaimella salattu avain.
avaimen varmistus (key confirmation) osoitus siitä että tietty avain on jonkun osapuolen hallussa. Pelkkä Diffie-Hellman tuottaa tämän.
eksplisiittinen avaimen a.
osoitus siitä että tietty avain on tietyn osapuolen hallussa. Yhdistää kaksi edellistä.

Esimerkiksi viime kerralla esillä olleella STS-protokollalla saavutetaan eksplisiittinen avaimen autentikointi. Siihen ymmärrettävästi pyritään useimmilla muillakin avaimenvaihdon protokollilla. On hyvä silti tietää, millaisista käsitteellisistä "palasista" tavoite koostuu.