Autentikointi eli todentaminen¶

Kapeasti määriteltynä autentikointi vahvistaa sisäänkirjautuvan käyttäjän identiteetin ja sitoo vastaavan käyttäjäidentiteetin toimijaan. Salasanoihin perustuva autentikointi on yleinen toteutustapa. Yksi vaihtoehto tälle on biometriikka. Hajautetuissa järjestelmissä autentikointi edellyttää usein avaimen perustamista (key establishment) autentikoidun istunnon hallitsemiseksi.

Tässä on kaksi Termipankin mukaista määritelmää ja selitystä osoittamaan, millä tasolla kansalaisten kuuluisi tuntea käsitteet. Jälkimmäinen niistä, pääsynhallinta, tule tässä materiaalissa käyttöön vain osana federoitua identiteetin- ja pääsynhallintaa, mutta sopivasti ajatellen se olisi kätevä kattamaan koko pääluvun sisällön.

Autentikointi tai todentaminen (authentication)

Menettely, jolla pyritään varmistumaan kohteen todenmukaisuudesta, oikeellisuudesta tai alkuperästä. Autentikoinnissa voidaan esimerkiksi tarkistaa varmenteiden avulla, onko järjestelmä se, johon käyttäjä haluaa yhteyden. Käyttäjän todentamiseen voidaan käyttää henkilökorttia tai mobiilivarmennetta. Kyberturvallisuuden yhteydessä autentikointi liittyy usein pääsynhallintaan (access management) ja sillä edistetään tietoturvaa.

Pääsynhallinta (access management)

Menettelyt, joilla varmistetaan, että käyttäjät, laitteet, sovellukset ja järjestelmät pääsevät käyttämään tietojärjestelmissä olevaa tietoa roolinsa mukaisesti.

Siirrytään nyt autentikoinnin täsmälliseen käsittelyyn - kaiken edellä olevan pohjalta. Autentikointi voi perustua olemukseen, “tekemykseen”, tietämykseen tai omistukseen. Asiat on tässä lueteltu pysyvimmästä muuttuvimpaan. Tietoturvamenettelyksi nämä ovat tulleet järjestyksessä tietämys, olemus, omistus, ja viimeisenä “tekemys” eli toiminta tai käyttäytyminen. Seuraavassa luettelossa tämä piirre on upotettu kahteen muuhun kohtaan, mikä tarjoaa selityksen sille, että luettelot usein esittävät vain kolme pääkohtaa.

Jotta olio voitaisiin autentikoida, eli todennetusti tunnistaa (tai havaita samaksi kuin aiemmin tavattaessa), sillä täytyy olla jokin todennettavissa oleva ominaisuus, jota muilla olioilla ei ole:

Se on jotain. Tämä tulee kyseeseen tietysti vain ihmisen tapauksessa. Erotteleva ominaisuus on siis fyysinen kuten sormenjälki, käden muoto, ääni, silmän verkkokalvo tai iiris, kasvojen lämpöjakauma, kallonmuoto. Tällaisten asioiden mittaamista kutsutaan biometriikaksi. Ominaisuus voi perustua myös käyttäytymispiirteisiin, kuten käsialaan, näppäilyyn, tai puheeseen.
Sillä on jotain fyysistä omistuksessaan, esim. avain, toimikortti tai muu token (tunniste-esine). Omistetun pitää tietysti olla jotain, jota ei voi helposti kopioida tai muuten väärentää. Omistava olio voi olla muukin kuin ihminen. Toimikortteja ovat esim. sähköinen henkilökortti, ja matkapuhelimen SIM.
Se tietää jotain, tyypillisesti salasanan ja yleisemmin jaetun salaisuuden. Tällaisen tiedon pitäisi mieluimmin olla sellaista, ettei sitä tarvitse paljastaa ja silti voidaan vakuuttua, että olio tietää sen. Tämän laatuinen tieto vastaa kykyä tehdä jotain yksilöllistä, jäljittelemätöntä. Yksityisellä avaimella allekirjoittaminen on tyypillinen esimerkki sellaisesta. Salaisuus ei silloin olekaan jaettu vaan epäsymmetrinen. Tieto voi luonnollisesti olla myös laitteen hallussa, jolloin tunnistetuksi tulee ensi kädessä kyseinen laite eikä sen käyttäjä (esim. puhelimen SIM, jolle ihminen toki autentikoituu ensin PIN-luvullaan). Paljastumatta jäävä tieto tarkastetaan haaste-vaste -menettelyllä, joka on jäljempänä esillä nimenomaan laitepohjaisesti.

Kaikkia näitä kolmea tapaa tarkastellaan myöhemmin tässä luvussa ja käyttäytymispohjaista myös erikseen. On tutkittu viidettäkin mahdollisuutta, sosiaalista verkostoa. Sen mukaan “olet joku tietty, koska tunnet juuri tietyt muut”. Sitä käytetään vanhastaan monessa arkisessa yhteydessä, mutta se ei tyypillisesti sovellu loogista täsmällisyyttä edellyttävään autentikointiin.

Varsinaisten autentikointiprotokollien suunnittelu on kypsä tietoturvatutkimuksen alue ja siihen liittyy hyvä tuki formaalin analyysin työkaluille. Standardiprotokollia, kuten Kerberos, SAML ja OAuth käytetään laajasti.

Identiteetin hallinta¶

Identiteetinhallinnan järjestelmät vastaavat sähköisten identiteettien luonnista, käytöstä ja poistamisesta. Luomisen yhteydessä pitää miettiä, kuinka vahvasti sähköisen identiteetin tulee olla sidottu henkilöön. Joskus vahvoja yhteyksiä on luotava ja dokumentoitava. Esimerkiksi rahanpesusäännöt voivat edellyttää tilinhaltijan henkilöllisyyden perusteellista todentamista. Joskus taas sähköistä identiteettiä ei tarvitse sitoa henkilöön. Esimerkiksi sisäänrakennettu yksityisyydensuoja (privacy by design) vihjaa, että tällaiset sovellukset käyttävät sähköisiä identiteettejä, joita ei voi yhdistää henkilöihin. Identiteetin hallinta voi myös linkittää pääsyoikeudet sähköiseen identiteettiin, joko suoraan tai jonkin välikerroksen, kuten roolin, kautta. Sähköisten identiteettien tulisi olla poistettavissa, kun niitä ei enää tarvita, esim. kun henkilö lähtee organisaatiosta. Tällöin on huolehdittava siitä, että tämä tehdään kaikissa järjestelmissä, joissa lähtijän sähköinen identiteetti on rekisteröity.

Identiteetin hallinta (identity management)

Menettelyt, joilla hallinnoidaan käyttäjien ja laitteiden tunnuksia, rooleja ja ryhmiä.

Sähköisiä identiteettejä on olemassa eri tasoilla. Järjestelmän sisäisiä tarkoituksia varten on identiteetit, esim. käyttöjärjestelmän käyttäjätunnukset. Näiden identiteettien on oltava paikallisesti yksikäsitteisiä ja ylläpitäjät voivat luoda niitä (Linuxissa). Tämä voi johtaa ongelmiin, kun identiteetti poistetaan käytöstä ja annetaan myöhemmin jollekulle toiselle. Uusi käyttäjä voi saada tahattomasti pääsyn resursseihin, joihin identiteetin edellisellä haltijalla oli pääsy. Kun organisaatiot sulautuvat, identiteettien välille voi syntyä törmäyksiä, joihin identiteetinhallinnan on puututtava. Vaihtoehtoisesti identiteetit voivat olla pitkiä satunnaisia merkkijonoja (Windowsissa). Todennäköisyys, että jokin äsken mainituista ongelmista ilmaantuu, on silloin mitätön, mutta kun käyttäjätili luodaan uudelleen, luodaan myös uusi satunnainen identiteetti ja sille on annettava pääsyoikeudet uudestaan.

Sähköiset identiteetit, kuten käyttäjänimet ja sähköpostiosoitteet, voivat olla satunnaisia merkkijonoja, mutta usein on parempi määrittää ymmärrettäviä identiteettejä. On kätevää viestiä osoitteeseen, jonka merkityksen pystyy näkemään. Sähköpostiosoite voidaan poistaa käytöstä ja tulla antaneeksi myöhemmin uudelle samannimiselle käyttäjälle, mutta silloin tämä voi saada edelliselle omistajalle tarkoitettuja sähköposteja.

Verkkosovellukset käyttävät usein sähköpostiosoitteita sähköisinä identiteetteinä. Tämä on kätevää käyttäjän tavoittamisen kannalta ja se on myös käyttäjille kätevää, koska heidän ei tarvitse muistaa uutta identiteettiä. On olemassa vaihtoehtoja, esim. FIDO UAF, jossa sähköiset identiteetit ovat satunnaisesti luotuja julkisia avaimia ja salasanojen resetointia ei tarvita, koska salasanoja ei käytetä.

Identiteettihallintaa voidaan tarkastella myös ihmisen näkökulmasta. Henkilö, joka käyttää eri identiteettejä eri organisaatioissa, saattaa haluta säädellä, miten identiteetti paljastuu eri organisaatioiden jäsenille.

Käyttäjän autentikointi¶

Käyttäjään liittyy melko pysyvä identiteetti, joka kytketään niihin melko väliaikaisiin toimijoihin (eli prosesseihin), jotka käyttäjä luo järjestelmään kirjautuessaan. Toimijoihin kytketty identiteetti on yksi niiden turva-attribuuteista. Muita voivat olla tiedot ryhmistä, rooleista, käyttörajoista ja elinkaaren aikana esiintyneistä tapahtumista. Käyttäjän autentikointi vahvistaa toimijan turva-attribuutit tuottamalla riittävän vakuuttuneisuuden siitä, että käyttäjäidentiteetti on oikea. Autentikoinnin vahvuuden eli vakuuttamisen asteen tulisi olla oikeassa suhteessa riskiin, jota halutaan vähentää.

Edellä oleva määritelmä on melkein sama kuin, että käyttäjä on kuka väittää olevansa. Erona on sen korostaminen, että käyttäjän luomat toimijat ovat niitä olioita, jotka kantavat käyttäjältä “perimiään” ominaisuuksia kun ne tekevät pääsypyyntöjä ja kohtaavat pääsynvalvonnan. Käyttäjä ei näitä tee, mutta käyttäjän autentikointi tukee toimijoiden kautta myös vastuullisuutta.

On olemassa pääsynvalvontajärjestelmiä, joissa toimijan turva-attribuutit säilyvät koko toimijan elinkaaren ajan. Monet käyttöjärjestelmät käyttävät tätä lähestymistapaa. Turvapolitiikan muutokset eivät vaikuta käynnissä oleviin prosesseihin, mutta koska niiden elinaika on rajoitettu, uusi politiikka pääsee ennen pitkää voimaan. Vaihtoehtoisesti toimijan attribuutit tarkistetaan aina, kun se lähettää pääsypyynnön. Esimerkiksi käyttäjä, joka on jo kirjautunut pankkisovellukseen, autentikoidaan uudelleen, kun hän tekee maksupyynnön. Näkökulma siirtyy tällöin toimijoista yksittäisiin pyyntöihin ja autentikointi tarkistaa, että päätöksentekoalgoritmille pyynnön yhteydessä lähetetyt turva-attribuutit ovat oikein.

Salasanat¶

Kun autentikointi on “jokin, jonka tiedät” -tyyppinen, voidaan käyttää salasanoja -lauseita tai -kuvioita. Kaikkiin pätee sama kuin tässä esitetään salasanoista. Suojatoimet järjestelmän puolelta sisältävät tiivistettyjen (Linux, Unix) tai kryptattujen (Windows) salasanojen varastoinnin, salasanojen suolauksen (salting), ja shadow-salasanatiedoston, joka siirtää arkaluonteiset tiedot pois kaikkien luettavissa olevista salasanatiedostoista. Suola on satunnaista dataa, joka syötetään salasanan kanssa tiivistefunktiolle, ja tiivistefunktion tuottama tiiviste varastoidaan salasanatiedostoon. Tiivisteen käyttö estää hyökkääjää saamasta selville salasanoja, vaikka salasanatiedosto paljastuisi. Suolan käyttö tiivistämisen yhteydessä suojaa salasanoja esim. sateenkaaritauluja käyttäviltä hyökkäyksiltä (rainbow table attacks).

	salasana	tiiviste (SHA256)
Tiina	salasana123	0d438c00cff7142df79b898680de63d92c9b9eb6f7dc926a87c580f6691a3cc1
Jukka	salasana123	0d438c00cff7142df79b898680de63d92c9b9eb6f7dc926a87c580f6691a3cc1

Yllä taulukossa käyttäjät ovat harjoittaneet kyseenalaista salasanavalintaa. Salasanat ovat paitsi äärimmäisen heikkoja, niistä laskettu tiiviste on täysin sama. Nyt jos hyökkääjä saa haltuunsa tiivisteet, hän voi heti päätellä, että kahdella käyttäjällä on sama salasana.

Alla taulukossa on havainnollistettu, miten tilanne paranee hieman, kun salasanoihin lisätään suola. Nyt hyökkääjälle ei tiivisteistä paljastu, että kahdella käyttäjällä on sama salasana. Tämä ei silti poista sitä tosiasiaa, että näiden käyttäjien tulisi vaihtaa salasanansa turvallisempaan välittömästi.

	salasana	suola	tiiviste (salasana + suola) (SHA256)
Tiina	salasana123	A43F567B3DFF7809	32afb2957edfb2b763b08a17bfed200b759314c1a374da57f93a673d973be91f
Jukka	salasana123	C341EF78CB20A512	69bc6396c0b04bccd28ad421f1fd3ca5c45f5e80b2967a016c50151565c32648

Käyttäjien näkökulmasta salasanojen suojaamiseen kuuluu käyttäjän opastaminen oikeanlaisten salasanojen käyttöön ja salasanojen hyvään hallintaan. Tähän pyrkivät esim. tietoturvatietoisuuden kampanjat, jotka yrittävät juurruttaa käyttäjiin sellaista toimintaa, joka varmistaa yhteyden henkilön ja järjestelmässä esiintyvän käyttäjäidentiteetin välillä. Suositukset tällä alueella muuttuvat jatkuvasti. NIST:n julkaisemat Digital Identity Guidelines -ohjeet perustuvat arvioihin aiempien salasanasääntöjen havaitusta tehokkuudesta ja ne huomioivat myös sen, että käyttäjien on nykyään hallittava useiden tilien ja palveluiden salasanoja. Suosituksissa neuvotaan

välttämään automaattista salasanojen vanhenemista, salasanat tulisi vaihtaa vain silloin kun siihen on syy;
välttämään monimutkaisia erikoismerkkejä viliseviä salasanasääntöjä, salasanan pituus on tärkeämpää kuin monimutkaisuus;
välttämään salasanavihjeiden tai tietoon pohjaavan autentikoinnin käyttöä (esim. turvakysymykset salasanan palauttamisen yhteydessä), koska esim. somesta löytyy nykyisin liikaa tietoa henkilöstä;
välttämään “näytä salasana kirjoittaessa” -vaihtoehtoa sekä välttämään tekstin liittämisen salasanakenttään sallimista.

Salasanapohjaiset etäautentikoinnin protokollat ovat RADIUS, DIAMETER, HTTP Digest Authentication ja jossain määrin Kerberos.

Biometriikka autentikointia varten¶

Salasanat toimivat huonosti käytännössä, koska ne kuormittavat käyttäjän muistia. Tästä seuraa turvattomia oikopolkuja, kuten saman salasanan käyttöä useissa palveluissa, liian lyhyitä ja helppoja salasanoja, tai epämääräisiä ja epäkäytännöllisiä salasananhallintatapoja. Biometriikka on vaihtoehto, joka välttää salasanapohjaiseen autentikointiin liittyvän kognitiivisen kuormituksen. Sormenjälki- ja kasvojentunnistus ovat kaksi pääasiallista biometristä autentikointitapaa. Biometriikka on esimerkki “jokin, jota olet” -tyyppisestä autentikoinnista.

Biometristen ominaisuuksien on oltava riittävän yksilöllisiä, jotta käyttäjät voidaan erottaa toisistaan niiden perusteella, mutta sormenjälkiä tai kasvoja ei voida pitää salaisuuksina. Biometrisiä ominaisuuksia käsitellään siten paremmin julkisena tietona esim., kun tehdään turva-analyysia. Autentikoinnin aikana järjestelmän on sallittava se, että biometriset ominaisuudet voivat vaihdella hieman, esim. sormi voi olla hikinen tai turvonnut lämpötilan vaikutuksesta. Tämä voidaan mahdollistaa joko autentikoivan laitteen tai järjestelmän ominaisuuksilla tai laittamalla ihminen valvomaan autentikointiprosessia. Lisäksi täytyy tarkistaa, että autentikoitava kohde on elävä, eikä esim. sormesta tehty malli. Biometrinen autentikointi käyttää seuraavia oletuksia:

Biometriset ominaisuudet identifioivat henkilön yksilöllisesti, esim. kasvot, sormenjäljet ja iiriskuviot.
Ominaisuudet ovat vakaita. Kuitenkin esim. ikääntymisen vaikutuksia sormenjälkien tunnistamiseen tutkitaan.
Ominaisuudet voidaan tallentaa helposti autentikointijärjestelmän käyttöasetuksiin.
Ominaisuuksia ei voi väärentää käyttäjän autentikoinnin aikana.

Käyttäjän biometrinen autentikointi (englanniksi yleensä verification), alkaa mallista, joka tallennetaan autentikointilaitteeseen. Mallista muodostetaan piirrevektori (feature vector). Malli voi olla esimerkiksi sormenjäljen kuva, piirteet ovat sormenjäljen yksityiskohtien paikat (esim. harjanteiden päätepisteet, haarautumat, kierteet jne.). Käyttäjät rekisteröivät aluksi referenssipiirrevektorin. Autentikoinnin aikana uusi malli luetaan sormenjäljestä, ominaisuudet poimitaan ja verrataan järjestelmään tallennettuun referenssiin. Käyttäjä autentikoituu, jos vastaavien ominaisuuksien määrä ylittää tietyn kynnyksen.

Prosessi voi epäonnistua useista syistä:

Piirteiden lukemisen epäonnistuminen: tämä voi tapahtua rekisteröinnin yhteydessä, jos ei saada luettua riittävää määrää ominaisuuksia, tai autentikoinnin aikana.
Väärät hylkäykset: todellinen käyttäjä hylätään, koska osumien määrä referenssiominaisuuksien ja autentikoinnin aikana luettujen ominaisuuksien välillä on riittämätön.
Väärät hyväksynnät: väärä käyttäjä hyväksytään, kun kynnysarvo jostain syystä ylittyy.
Väärennös: tunnistusjärjestelmää huijataan esim. sormesta tehdyllä mallilla. Elävyyden tarkistus yrittää varmistaa, että mallit luetaan oikeasta henkilöstä, jota ollaan autentikoimassa.

Kasvojentunnistukseen tai sormenjälkiin perustuvaa biometristä tunnistamista käytetään yhä enemmän esim. automaattisilla rajavalvonta-asemilla. Biometrinen autentikointi puolestaan on esim. mobiililaitteiden ominaisuus. Kun käyttäjää tunnistetaan biometriikkaan perustuen, tarvitaan enemmän biometristä dataa kuin autentikointiin, joka onnistuu osittaisellakin datalla. Tästä erosta seuraa esimerkiksi erilaisia turvallisuus- ja yksityisyysongelmia. Onkin hyvä ymmärtää, että biometriikan käyttö autentikointiin ja tunnistamiseen ovat eri asioita ja järjestelmien suunnittelussa tulisi huomioida tämä. Jos ero ei ole sinulle selvä, lue lisää esim. tästä.

Autentikointitokenit¶

Kun autentikointi perustuu käyttäjille annettuun laitteeseen (eli tokeniin tai turva-avaimeen, huom. tämä on eri asia kuin kryptogafiset avaimet), laite laskee kertasalasanan (one-time password, OTP), joka on synkronoitu autentikaattorin kanssa tai on vastaus autentikaattorin asettamaan haasteeseen. Laitteen hallussapito on tällöin välttämätön onnistuneelle autentikoinnille, joka on siis “jokin, joka sinulla on” -tyyppinen.

Token voi olla pieni kädessä pidettävä laite, jossa on LED-näyttö kertasalasanalle, jonka käyttäjä syöttää sisäänkirjautuessaan, esim. RSA SecurID ja YubiKey. Tokenissa voi olla LED-näytön lisäksi numeronäppäimistö ja “allekirjoita” -nappi. Tällöin laitteen haltija voi saada haasteen, esimerkiksi 8-merkkisen numeron, syöttää sen näppäimistöllä, painaa ‘allekirjoitus’-nappia pyytääkseen tokenia laskemaan ja näyttämään vastauksen, ja syöttää sitten vastauksen kirjautuessaan. Jotkut verkkopankkipalvelut käyttävät tämän tyyppistä tokenia tilinhaltijan autentikointiin. PhotoTAN-laitteilla haaste lähetetään QR-koodina käyttäjän tietokoneeseen ja skannataan näytöltä PhotoTAN-laitteella. Kun autentikointi perustuu jaettuun salaisuuteen (shared secret) tokenin ja palvelimen välillä, eri palvelimille tarvitaan eri tokenit.

FIDO-autentikaattori on token, joka voi luoda julkisen avaimen/yksityisen avaimen pareja. Julkiset avaimet toimivat tunnisteina ja yksityisiä avaimia käytetään digitaalisten allekirjoitusten luomiseen. FIDO UAFissa, käyttäjät rekisteröivät julkisen avaimen palvelimelle. Samaa tokenia voidaan käyttää eri palvelimilla, mutta eri avaimilla. Käyttäjän autentikointi perustuu haaste-vaste -menetelmään, jossa käyttäjän autentikaattorilaite allekirjoittaa digitaalisesti vastauksen palvelimen esittämään haasteeseen. Vastaus verifioidaan palvelimelle rekisteröidyllä julkisella avaimella.

Joissakin sovelluksissa tokenin hallussapito riittää käyttäjän autentikointiin. Toisissa autentikointi on kaksivaiheinen prosessi. Ensin token autentikoi käyttäjän, esimerkiksi PIN-koodin tai sormenjäljen perusteella. Toisessa vaiheessa palvelin autentikoi tokenin. Uhkamallista riippuu, tarjoaako tämä “heikon” ja “vahvan” vaiheen yhdistelmä riittävästi turvaa.

Älypuhelimien sovellukset voivat tarjota samat toiminnot kuin autentikointitokenit, mutta älypuhelimet eivät ole erityisiä turvalaitteita. Käyttäjän autentikointi saattaa tällöin vaarantua älypuhelimeen kohdistuvien hyökkäysten kautta. Ne voivat vielä helpottua, jos älypuhelin tarjoaa toissijaisen autentikoinnin ollessaan osittain lukittu. Tämä on käyttäjälle vähemmän työläs, mutta myös vähemmän turvallinen menettely. Syntyy ristiriita, jossa laitevalmistajien etu olisi puhelimien helppokäyttöisyys, mutta arkaluonteisten sovellusten tarjoajien etu olisi token-tasolle yltävä turvallisuus.

Käyttäytymisperusteinen autentikointi¶

Käyttäytymisperusteinen autentikointi analysoi “mitä teet” ja soveltuu jatkuvaan autentikointiin. Esimerkkejä ovat näppäilydynamiikka, jota voidaan tallentaa ilman erityisiä laitteita; käsin kirjoittaminen, jolle ominaisia piirteitä ovat kirjoitusnopeus ja kynän paine, tällöin autentikointitarkoituksessa on käytettävä erityisiä kyniä tai kirjoituslehtiä; ja äänentunnistus, joka tarvitsee mikrofonin. Älypuhelimissa on erilaisia antureita, kuten kosketusnäyttöjä ja mikrofoneja, joita käytetään nykyään käyttäytymisperusteiseen autentikointiin. Käyttäytymisperusteista autentikointia koskevat vaatimukset ovat samat kuin biometriikan yhteydessä luetellut:

Käyttäytymispiirteet identifioivat henkilön yksilöllisesti.
Piirteet ovat vakaita, eivätkä tilapäiset häiriöt vaikuta niihin.
Piirteet voidaan tallentaa helposti autentikointijärjestelmän käyttöasetuksiin.
Piirteitä ei voi väärentää käyttäjän autentikoinnin aikana.

Jatkuvan autentikoinnin kannattajat lupaavat minimaalisen haitan käyttäjälle ja maksimaalisen turvallisuuden. Käyttäytymisperusteinen autentikointi ei haittaa käyttäjää, koska autentikointiin ei tarvita mitään muuta kuin normaali toiminta, mutta vaihtelut käyttäytymisessä voivat aiheuttaa vääriä hylkäyksiä. Esimerkiksi kuinka vilustuminen vaikuttaa puheentunnistukseen? Turvallisuus taas riippuu siitä, miten hyvin tunnistetaan, että autentikoituja on oikea, elävä henkilö, eikä esimerkiksi puhesyntetisaattori tai hyvin taitava imitaattori. Ilman tarkkaa uhkamallia, käyttäytymisperusteinen autentikointi voi tarjota vain epävarmoja turvallisuustakuita. Erilaisista käyttäytymisperusteisen autentikoinnin menetelmistä tehdään paljon tutkimusta. Kriteereitä tutkimuksen hyödyllisyyden arvioimiseksi ovat otoksen koko ja koostumus, onko pitkittäistutkimuksia tehty, tarkan uhkamallin olemassaolo ja vastustuskyky kohdistettuja impersonointihyökkäyksiä vastaan.

Kaksivaiheinen autentikointi (2FA)¶

Monivaiheinen autentikointi (multifactor authentication, MFA) yhdistää useita käyttäjän autentikointimenetelmiä turvallisuuden parantamiseksi. Euroopan maksupalveludirektiivi 2 (PSD2, direktiivi (EU) 2015/2366) rahoituspalveluntarjoajien sääntelyä varten edellyttää kaksivaiheista autentikointia verkkomaksuille (muutamin poikkeuksin). PSD2 on siis esimerkkitapaus laajamittaisten 2FA-ratkaisujen käyttöönotosta.

Kaksivaiheisen autentikoinnin kaksi tekijää voivat olla salasana ja autentikointitoken. Niistä lasketaan tapahtuman autentikointiluvut (transaction authentication numbers, TAN), jotka on sidottu yksikäsitteisesti myös tapahtuman sisältöön. Token voi olla erillinen laite. Jos se on sidottu vain yhteen maksupalveluun, asiakkaalla pitää olla useita laitteita. Useiden palveluiden kanssa toimivilta laitteilta edellytetään jonkinasteista standardointia. FIDO alliance on laatinut standardeja PSD2-yhteensopivaa kaksivaiheista autentikointia varten.

Token voi olla myös palveluun rekisteröity älypuhelin. Tällöin asiakkaat voivat asentaa sovelluksia useita palveluita varten samalle laitteelle. Tätä lähestymistapaa ovat suosineet monet pankit. Kuitenkin, kun sama laite käsittelee salasanoja (tai PIN-koodeja) ja TAN-koodeja, kaksi mekanismia eivät ole enää riippumattomia, mikä vähentää 2FA:n väitettyjä turvallisuushyötyjä.

Eurooppalainen luottamuspalveluita ja sähköistä tunnistamista koskeva asetus (eID-direktiivi – asetus (EU) N:o 910/2014) määrittelee vaatimukset suojatun allekirjoituksen luomiseen käytettäville laitteille. PSD2 ei aseta tietoturvavaatimuksia käyttäjien autentikointiin käytettäville laitteille, mutta haluaa “sallia kaikkien yleisten laitteiden (kuten tietokoneiden, tablettien ja matkapuhelimien) käytön erilaisten maksupalvelujen suorittamiseen”. Siten PSD2 ja eID-direktiivit tasapainottuvat eri tavoin käytettävyyden ja turvallisuuden välille. Näiden tasapaino on tunnetusti vaikeasti toteutettavissa oleva kompromissi.

Autentikointi hajautetuissa järjestelmissä (syventävä)¶

Hajautettujen järjestelmien käyttäjien prosessien sijasta pääsynvalvonta perustuu autentikoituun istuntoon (session), ja ne puolestaan perustuvat kryptografisiin avaimiin. Niitä kutsutaan istuntoavaimiksi ja niiden muodostaminen (key establishment) on käyttäjän autentikoinnin ydinominaisuus. Esimerkin tästä tarjoaa seuraavassa Kerberos.

Kerberos (syventävä)¶

Kerberos on MIT-yliopistossa 1980-luvun lopulla kehitetty autentikointipalvelu, jossa käytetään luotettua kolmatta osapuolta ja symmetristä salausta. Käyttäjän kannalta järjestelmä toteuttaa kertakirjautumisen periaatetta (single-sign-on) verkossa oleviin palveluihin. Yleisimmät käyttöjärjestelmät ovat sittemmin omaksuneet Kerberoksen tai sen muunnelmia käyttäjän autentikointia varten. Esimerkiksi Windows-toimialueen käyttäjätietokanta ja hakemistopalvelu Active Directory käyttää sitä – yhdessä LDAP-hakemistoprotokollan kanssa.

Tavoitteena on asiakkaan autentikoituminen kohdepalvelimelle S. Luotettu kolmas osapuoli on Kerberos Authentication Server eli KAS, johon asiakkaalla on salasana. Siitä sekä asiakas että KAS johtavat symmetrisen salausavaimen K. Vastauksessaan asiakaspyyntöön KAS lähettää asiakkaalle salatun istuntoavaimen ja salatun lipun palvelua S varten. Asiakas saa K:lla salatun istuntoavaimen auki käyttäen salasanaansa. Istuntoavaimella asiakas salaa oman tunnisteensa (ja aikaleiman), ja lähettää tuloksena olevan autentikaattorin yhdessä lipun kanssa palveluun S. Palvelu S toteaa asiakkaan autenttiseksi, koska S saa lipun auki S:n ja KAS:n välisellä avaimella ja lipusta löytyy samainen istuntoavain, jolla autentikaattori aukeaa ja näyttää asiakkaan tiedot.

Ticket Granting Server (TGS) muodostaa lisäkerroksen asiakkaan ja kohdepalvelimen välille. Protokolla toistuu melkein samanlaisena kahdesti: TGS toimii ensi vaiheessa kuin S edellä ja lopuksi kuin KAS. Toimien eriyttämisellä tavoitellaan taloudellisuutta: KAS-palvelimeen (ja sen pääsyoikeustietokantaan) ollaan yhteydessä kertaalleen käyttäjän kirjautuessa koneelleen. Sen jälkeen samalla KAS:n myöntämällä TGT-lipulla (ticket-granting ticket) asioidaan TGS:ssä kerran kutakin käytettävää palvelutyyppiä kohden ja siltä saadulla lipulla (“service-granting” ticket) käytetään sitten kohdepalvelua niin usein kuin tarvitaan. Myös TGS voi soveltaa pääsynvalvontaa päättäessään, antaako se lipun käytettäväksi palvelimen S kanssa.

Kerberos sai nimensä siitä, että sillä on kolmenlaista tehtävää. Autentikoinnin lisäksi sillä voi toteuttaa tämän pääluvun kahta muuta pääaihetta eli valtuutusta ja vastuullisuutta (ks. selityksen taustaksi kuva oikeasta Kerberoksesta). Muita protokollia näihin kolmeen tarkoitukseen ovat RADIUS, Diameter ja TACACS+.

Kerberos toimii myös federoidussa käyttäjähallinnassa. Sellaiseen sopivaa samantapaista lipun välitystä löytyy myös standardeista

SAML, Security Assertion Markup Language: turva-assertiot ovat väitteitä mm. siitä että jollakulla on oikeus johonkin resurssiin. SAML sisältää myös määritykset protokollaviestejä varten.
OAuth, Open authoraziation. Tässä on kyse erityisesti delegointien välittämisestä. Tämän päällä toimii:
OpenID Connect, joka keskittyy autentikointiin.