SECURELuottamuksenhallintaa epävarmuuden keskellä

SECURELuottamuksenhallintaa epävarmuuden keskellä Sini Ruohomaa Helsinki 25.4.2005 Seminaariartikkeli HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty Matemaattis-luonnontieteellinen tiedekunta Tietojenkäsittelytieteen laitos Tekijä Författare Author Sini Ruohomaa Työn nimi Arbetets titel Title SECURELuottamuksenhallintaa epävarmuuden keskellä Oppiaine Läroämne Subject Tietojenkäsittelytiede Laitos Institution Department Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Seminaariartikkeli 25.4.2005 13 sivua Tiivistelmä Referat Abstract Uusissa liikkuvan tietojenkäsittelyn sovelluksissa tarvitaan mitä moninaisempien laitteiden yhteistoimintaa. Ympäristöön liittyy paljon epävarmuutta ja riskejä, mikä vaikeuttaa tasapainon löytämistä kunkin autonomisen järjestelmän itsesuojauksessa: täysin suljettu järjestelmä on varsin turvallinen, mutta joitakin haluttuja toimintoja voidaan toteuttaa vain avautumalla yhteistyölle. Tämä tutkielma esittelee SECUREprojektin suunnitteleman, luottamuksen käsitteeseen perustuvan tietoturvajärjestelmän, joka tukee perusteltua riskinottoa yhteistoiminnan mahdollistamiseksi. ACM Computing Classication System (CCS): H.5.3 [Information Interfaces and Presentation: Group and Organization Interfaces] K.6.5 [Management of Computing and Information Systems: Security and Protection] Avainsanat Nyckelord Keywords luottamuksenhallinta Säilytyspaikka Förvaringsställe Where deposited http://www.cs.helsinki.fi/u/karvi/turva_seminaarik05.html Muita tietoja övriga uppgifter Additional information Tietoturva: Luottamus ja varmuus -seminaariartikkeli

Sisältö iii 1 Johdanto 1 2 Ympäristön vaatimukset 2 3 Luottamuspäätöksen tekijät 3 4 Luottamuksen hallinnan osamallit 5 4.1 Luottamuksen tietomalli......................... 5 4.2 Riskin tietomalli............................. 7 5 Pohdintaa 10 6 Yhteenveto 13 Lähteet 13

1 Johdanto Älykkäiden kodinkoneiden ja pienlaitteiden yleistyessä myös erilaiset tavat yhdistää nämä toimimaan keskenään valtaavat alaa. Esimerkiksi tulevaisuuden automatisoidussa kodissa pesukone voi kysyä kuivauskaapilta, miten edellisen pyykkilastin kuivuminen etenee, ja valita hitaamman ohjelman mikäli kaappiin tulisi ensin saada lisää tilaa. Kun lähes kaikissa laitteissa ympärillämme on jonkinlaista älykkyyttä ja mahdollisesti jopa etäohjauksen mahdollisuus, kämmenmikrojen ja muiden aktiiviseen viestintään ympäristönsä kanssa sopivien laitteiden rooli on muuttumassa puhelimesta tai muistikirjasta eräänlaiseksi yleiskaukosäätimeksi, jolla voi kenties laittaa saunan lämpiämään jo matkalla kotiin, tulostaa vierailullaan lähimmällä tulostimella ilman monimutkaista asetushallintaa, ostaa bussilippuja anonyymisti tai vaikkapa kysellä viereisen kämmenmikron osoitekirjan tietoja. Tällainen autonomisten ja liikkuvien laitteiden yhteistoiminta vaatii, että kukin laite voi suojata itseään pahantahtoisilta yhteistyökumppaneilta sulkeutumatta täysin ulkomaailmalta. Koska laitteet eivät ole jatkuvasti yhteydessä verkkoon, niiden tulee voida tehdä itsenäisiä päätöksiä. Päätökset koskevat myös sellaisia toimijoita, joiden kanssa laitteet eivät ole koskaan olleet tekemisissä. Tähän nykyiset jähmeät pääsynhallinta- ja autentikaatiojärjestelmät eivät riitä. Esimerkiksi kämmenmikro, jolta yhteystietoja kysellään, voi antaa virheellisiä vastauksiaesimerkiksi tietojen vanhettua. Lähin tulostin saattaa tulostaa tietynlaisia tiedostoja väärin tai jättää ne tulostamatta, mutta toinen paikallinen kämmenmikro on kenties saanut hankalankin tiedoston paperille toisella tulostimella. Pesukoneenkin olisi hyvä lakata konsultoimasta kuivauskaappia, mikäli laite väittää epäkuntoon menneiden sensorien takia jatkuvasti että sen sisällä on läpimärkää pyykkiä. SECURE (Secure Environments for Collaboration among Ubiquitous Roaming Entities) on laaja, viiden yliopiston yhteistyöprojekti, joka kehittää kehikkoa luottamuksenhallintaan erityisesti ympäristöissä, joissa toisten toimijoiden tarkka tunnistaminen on vaikeaa [CGS + 03]. Ympäristö asettaa erityisiä vaatimuksia kehitellylle luottamuksenhallintajärjestelmälle, jonka tulee voida tehdä päätöksiä myös epävarman tiedon pohjalta. Luottamus on tässä yhteydessä lähinnä McKnightin ja Chervanyn Trusting intention [MC96] -merkitystäpositiivinen luottamuspäätös ilmaisee juuri tahtoa jatkaa yhteistoimintaa riskeistä huolimatta. Tämä seminaariartikkeli käsittelee SECURE-projektin luottamuksenhallinnan mallin keskeiset osat: luottamuksen ja riskin esityksen, luottamuspäätöksen periaatteet sillä tarkkuudella kuin niitä on lähteissä kuvattu, sekä hahmottelee hieman luottamustiedon ylläpitoa tarkkailun pohjalta. Teoriaa selvennetään päälähdettä [CGS + 03] löyhästi seuraten osoitekirjan päivittämistä, sähköistä lompakkoa ja korttipeliä ad hoc -ryhmässä käsittelevillä esimerkeillä.

2 2 Ympäristön vaatimukset SECURE kehittää luottamuksenhallintajärjestelmänsä arvioinnin helpottamiseksi esimerkkisovelluksia. Näille on yhteistä riippumattomuus keskitetystä tunnistus- ja auktorisointipalvelusta, usean itsenäisen, mahdollisesti keskenään tuntemattoman tahon yhteistoiminta ja siihen liittyvä riski, joka tulee ottaa huomioon päätöksenteossa. Lisäksi luottamuspäätöksen jälkeen toimintaa seurataan, jotta sen todellinen lopputulos voidaan lisätä kokemustietoon ja sitä kautta saada päivitettyä luottamuksen määrää. Pääesimerkki on sähköinen lompakko, sovellus jota ajetaan esimerkiksi kännykässä. Käyttäjä rekisteröityy ensin pankissa. Hän saa pankilta lompakolleen PIN-koodin ja pankin allekirjoittaman varmenteen, joka sisältää käyttäjän tunnisteen ja julkisen avaimen. Tunniste piilottaa käyttäjän henkilöllisyyden pseudonyymin taakse; täten kauppias voi erottaa käyttäjän muista käyttäjistä ja kerätä tähän liittyen luottamustietoa 1, muttei kykene yhdistämään tunnistetta käyttäjän henkilötietoihin. Koska PIN-koodi tarvitaan ostosten tekemiseen, kännykän kadottaminen ei ole yhtä vakavaa kuin tavallisen lompakon katoaminen. Lisäksi pankki kykenee tunnistamaan käytetyt sähköiset kolikot riittävällä tarkkuudella voidakseen havaita, yritetäänkö samaa sähköistä kolikkoa muuttaa takaisin rahaksi useammin kuin kerran. Perussovellus vaikuttaa päällisin puolin vastaavan suomalaista korttirahaa, jota voidaan ladata automaatista pankkikortin sirulle, mutta korttirahassa ei käytetä PIN-koodia. Asiakas siis vaihtaa pankissa rahaa muotoon, jonka voi tallettaa sähköiseen lompakkoonsa. Tämän jälkeen hän voi maksaa kännykällään ostoksia kuten käteisellä, myös silloin, kun pankkiin ei välittömästi saada yhteyttä. Kauppias ottaa suurimman riskin, sillä pankki voi kieltäytyä myöhemmin ottamasta vastaan rahaa, joka oli väärennettyä. Kauppiaan kannalta ostolla on siis kaksi lopputulosta: joko hän saa rahaa joka kelpaa pankille, tai hän saa väärennettyä rahaa. Kauppiaan ottaman riskin voidaan katsoa olevan lineaarisesti riippuvainen ostoksen koosta. Luottamusta voidaan mitata onnistuneiden ja kauppiaan kannalta epäonnistuneiden ostojen lukumäärillä. Mobiililaitteilla pelattavassa uhkapelissä rahallinen riski ilmenee kahdella tasolla. Ensimmäinen, haluttu riskityyppi liittyy pelin kulkuun: pelin päättyessä häviöön panos menetetään, kun taas voittaja saa lisää rahaa. Tämä riski on osa pelin kiinnostavuutta, eikä sitä ole tarpeen hallita luottamuksen avulla. Toinen, pelin toteutttamisessa käytettyyn teknologiaan sidottu riski liittyy siihen, että pelin tulokset, voitot ja häviöt, eivät riipu yksin onnesta ja taidosta, vaan joku osallistuja huijaa. Huijaaminen on mahdollista paitsi tavallisilla pelikorteilla, myös niitä simuloivilla mobiililaitteilla. Huijatuksi tulemisen riskiä voidaan pyrkiä hallitsemaan luottamuksen avulla. Uhkapeliä, kuten esimerkissä Black Jack -korttipeliä, voidaan pelata satunnaisella joukolla esimerkiksi junamatkan aikana. Pelaajan pääsy mukaan peliin riippuu 1 Pitkäaikaiset identiteetit ovat yksi toimivan mainejärjestelmän edellytyksistä, kuten Resnick et al. toteavat [RZFK00].

3 Kuva 1: Luottamuksenhallintajärjestelmän osat [CGS + 03]. Ohuet nuolet kuvaavat kontrollin kulkua, paksut tiedon siirtymistä. heidän luotettavuudestaan; tämän arvioinnissa kolmansien osapuolten suositukset voivat olla tarpeen, sillä junamatkustajat eivät välttämättä ole koskaan tavanneet. Tällöin myöskään pelilaitteilla, esimerkiksi kännyköillä, ei ole aiempaa kokemusta toisistaan. Suosituksia voidaan tehdä paitsi järjestelmän sisäisesti, myös suullisesti, sähköpostilla tai puhelimitse, jolloin käyttäjä voi itse tallentaa ne järjestelmään. Toisaalta pelaajan pääsy jakajaksi voi vaatia suurempaa luottamusta kuin peliin osallistuminen, sillä Black Jackissä jakajan voittomahdollisuudet ovat paremmat. Luottamuksen kannalta mielenkiintoiset lopputulokset liittyvät paitsi reilun pelin toteamiseen, myös siihen, että hävinneet pelaajat maksavat velkansa. Pelin reiluudesta vakuuttuminen ei ole täysin triviaalia; huijaaja voi esimerkiksi muuttaa omia korttejaan muokatulla peliohjelmalla, tehdä yhteistyötä aiheuttaakseen toisen pelaajan voiton tai väittää olevansa joku muu matkustaja ja hävitä tahallaan. 3 Luottamuspäätöksen tekijät Luottamuspäätös kuvastaa halukkuutta sallia tietyn toimijan tehdä jotakin, esimerkiksi pelata korttipeliä, ostaa jotakin tai vaikkapa päivittää tietoja omasta puhelinmuistiostaan luottajan muistioon. Päätöksen pohjaksi tarvitaan useita tekijöitä. Kuva 1 esittää yhden toimijan sisäistä luottamuksenhallintajärjestelmää. Oikealla näkyy ohjelmointirajapinnan kautta saatu pyyntö luottamuspäätökselle. Pyyntö välitetään analysoijakomponentille (kuvassa Request analyzer), joka kysyy aluksi tunnistuskomponentilta (Entity recognition), voidaanko kysyjä tunnistaa riittävän uskottavasti. Komponentti voi myös ilmoittaa, ettei kysyjää ole tavattu aiemmin.

4 Tunnistuksen perusteella luottamuksen laskentakomponentti (Trust calculator) arvioi luottamuksen määrän kyseiseen toimijaan. Sähköisen lompakon esimerkissä luottamusarvo koostui hyvien ja huonojen kokemusten määrästä, (m, n). Tämä esitysmuoto määräytyy paikallisen politiikan mukaan, ja se kootaan aiemmista kokemuksista. Luottamusarvojen yleisiä rajoituksia käsitellään luvussa 4.1. Mikäli ilmoitettu luottamus, esimerkiksi tuntemattomalla käyttäjällä arvo (0, 0), ei riitä positiiviseen päätökseen muttei puolla negatiivistakaan, voi luottamuksen laskentakomponentti hakea lisätietoa luottamuksen elinkaaren hallintakomponentin kautta (Trust lifecycle management). Tämä saa uutta tietoa kokemuskannasta (Evidence store), johon muualta saadut suositukset ja omat aiemmat kokemukset saapuvat. Suositusten ja omien kokemusten käsittelyä ohjaa myös paikallinen politiikka; sen säännöt voivat esimerkiksi määrätä, että omat kokemukset vaikuttavat luottamusarvoon yksi yhteen, kun taas suosituksista saadut hyvien ja huonojen kokemusten lukumäärät jaetaan kahdella ennen lisäämistä luottamusarvoon. Mikäli kokemuskanta sisältää tietoa, jonka avulla arvoa saadaan päivitettyä, uusi arvo välittyy analysoijakomponentille. Muussa tapauksessa päätöksestä saattaa lopulta tulla yksinkertaisesti en tiedä. Päivityskierros kokemuskantaan saatetaan tehdä myös muista, jälleen paikallisen politiikan määräämistä syistä. Jotta luottamuksesta saadaan toimintokohtaista, kokemuskannan tulee säilyttää myös tieto siitä, mihin toimintoon tietty kokemus liittyi. Tällöin luottamuksen laskentakomponentti voi yhdessä elinkaaren hallinnan kanssa suodattaa dynaamisesti käyttöön vain ne kokemus- ja suositustiedot, jotka ovat relevantteja viimeisimpään pyyntöön liittyneen toiminnon kannalta. Tuloksena oleva luottamusarvo voi tällöin erota suuresti kaikkein yleisimmästä arvosta. Esimerkiksi jos samaa luottamuksenhallintajärjestelmää käytetään puhelinmuistion päivityksissä ja korttipelissä, yhdeltä alueelta saatu positiivinen kokemus ei välttämättä implikoi millään tavalla luotettavuutta toisella alueella, mutta jos muistion päivityksiä on huomattavasti enemmän, voisivat negatiiviset kokemukset korttipelissä jäädä niiden varjoon käytettäessä yleistä kokemuslaskennan tapaa. Paikalliset politiikat vaikuttavat siis luottamustiedon käsittelyyn. Niiden toinen rooli liittyy myös läheisesti luottamuksen laskentakomponenttiin. Joskus luottamuksen laskijaksi voidaan nimittäin eksplisiittisesti valtuuttaa jokin toinen toimija (kuvassa Synchronous communication). Sähköisen lompakon esimerkissä suuren rakennuksen kaikki kahviautomaatit voivat olla yhteydessä yhteen keskukseen, joka hoitaa kahvin ostoon liittyvät luottamuspäätökset niiden puolesta. Valtuutus kuitenkin edellyttää, että tämä yhteys on saatavilla päätöksentekoaikaan. Valtuutus voi olla vain osittaista; mikäli odotusaulaan sijoitettu kahviautomaatti olisi sattumalta varustettu myös Blackjack-jakajan ohjelmistolla, se voisi tehdä korttipeliin liittyvät luottamuspäätökset yhä itsenäisesti. Luottamusta ei tarvittaisi ilman riskiä, joten riskianalyysi on tärkeä osa luottamuspäätöstä. Kun luottamusarvo on selvitetty, sen avulla järjestelmän yleinen riskiarvioiden perhe voidaan pelkistää arvioksi tietyn toimijan suhteen. Arviot saadaan riskinarviointikomponentista (Risk evaluator), joka päivittää riskiarvioitaan

aiemman kokemuksen perusteella. Riskiasetuskomponentti (Risk conguration) kerää kokemuskannasta tämän päivitykseen tarvittavan tiedon. Riskinhallintaa käsitellään tarkemmin luvussa 4.2. Lopulta luottamusarvon avulla johdetun riskiarvion perusteella tehdään luottamuspäätös analysointikomponentissa. Paikalliset politiikat määräävät tietyt raja-arvot päätökselle. Positiivisen luottamuspäätöksen jälkeen toiminta sallitaan. Sitä tarkkaillaan toiminnon keston ajan, ja tarkkailusta vastaava komponentti (Monitoring) päivittää kokemuskantaa toiminnan lopputuloksen mukaisesti. 5 4 Luottamuksen hallinnan osamallit Kuten edellisessä luvussa nähtiin, luottamuspäätöksen kaksi keskeisintä tekijää ovat arviot luottamuksesta ja myönteisellä päätöksellä sallittuun toimintaan liittyvästä riskistä. Seuraavassa kahdessa luvussa riski- ja luottamustiedon esitysmuotoa käsitellään lähemmin. Kokemustiedon muotoa ei artikkelissa kuvailla lähemmin, mutta sitä ja luottamustiedon päivitystä on käsitelty toisaalla [WCE + 03]. Toimijoiden tunnistamisen malli on kuvailtu samoin aiemmassa lähteessä [SFJ + 03]. 4.1 Luottamuksen tietomalli Edellä esimerkissä esitelty hyvien ja pahojen kokemusten lukumäärällä esitetty luottamusarvo (n, m) on vain yksi mahdollisista luottamuksen esitystavoista. SECURE esittää artikkelissa luottamuksen formaalin tietomallin, joka sisältää tämän luottamusarvojen muodon ja monia muita. Olkoon P toimijoiden joukko, ja T luottamusarvojen joukko. Luottamuspäätöksessä käytettävä luottamustieto voidaan ilmaista kahden toimijan a ja b P funktiona, jonka arvo m(a)(b) = t kuuluu luottamusarvojen joukkoon T ja ilmaisee toimijan a luottamuksen toimijaan b. Luottamusarvot T koostuvat intuitiivisen tulkinnan mukaan arvioista siitä, mikä olisi tämän toimijan käytöstä täysin oikein ennustava luottamusarvo. Arviot voivat ilmoittaa esimerkiksi välin, jolle tämä ennustava arvo nykytiedon mukaan sijoittuu. Luottamusarvo on ilmaistavissa esimerkiksi lukuna välillä [0, 1], missä 1 on suurin mahdollinen luotettavuus. Tällöin funktio voisi saada kolmelle toimijalle a, b ja c seuraavat arvot: m(a)(b) = [0, 4; 0, 6] ja m(a)(c) = [0, 2; 0, 3]. Luottamusarvojen joukko T voidaan järjestää kahdella eri tavalla. Yksinkertaisin näistä kahdesta on arvion tarkkuuden mukainen osittaisjärjestys (T, ), jolla on oltava minimiarvo. Elementti kuvaa suurinta mahdollista epävarmuutta, ja se on kaikkien täysin tuntemattomien toimijoiden luottamusarvo-oletus. Esimerkin luottamusarvot voidaan tämän vaatimuksen toteutumiseksi järjestää niiden ilmaisemien välien pituuden mukaisesti laskevaan järjestykseen. Tämän järjestyksen mukaan m(a)(b) m(a)(c), koska välin [0, 4; 0, 6] pituus on 0, 6 0, 4 = 0, 2,

6 Kuva 2: Hyvien ja huonojen kokemusten määriin perustuvien luottamusarvojen järjestys [CGS + 03]. Tiedon määrä kasvaa alhaalta ylöspäin siirryttäessä viivoja pitkin; luottamuksen määrä kasvaa vasemmalta oikealle. kun taas pienempi väli [0, 2; 0, 3] on pituudeltaan vain 0, 3 0, 2 = 0, 1 ja täten ilmaisu on tarkempi. Tämän osittaisjärjestyksen ensimmäinen eli epätarkoin elementti on tässä tapauksessa koko arvovälin kattava elementti [0, 1]. Arvion edustaman luottamuksen mukainen järjestys on hieman monimutkaisempi. Osittaisjärjestyksen (T, ) vaatimukset ovat tiedon määrän mukaista järjestystä löyhemmät: sen on oltava täydellinen hila (complete lattice), jolloin muun muassa kaikkien arvojen ei tarvitse olla vertailtavissa keskenään. Tälläkin järjestyksellä on oltava minimielementti, joka kuvastaa minimaalista luottamusta. Luottamuksen mukainen järjestäminen arvoväliesimerkissä kulkee intuitiivisesti niin, että suurempia lukuja sisältävä väli kuvaa suurempaa luottamusta. Esimerkkitapauksessa jako on yksinkertainen: m(a)(c) m(a)(b), koska välin [0, 4; 0, 6] kaikki arvot ovat suurempia ja siten kuvastavat suurempaa luottamusta kuin välin [0, 2; 0, 3]. Osittain tai täysin päällekkäisten välien, kuten [0, 2; 0, 3] ja [0, 24; 0, 26], järjestäminen ei enää onnistukaan. Voidaan määrittää, että kahdelle arvolle X ja Y pätee tällöin X Y jos ja vain jos pätee sup(x) sup(y ) ja inf(x) inf(y ). Merkintä sup(x) tarkoittaa X:n supremumia l. pienintä ylärajaa ja inf(x) X:n inmumia l. suurinta alarajaa: jos X on puoliavoin väli [0, 1), on sen supremum 1 ( x X : x 1) ja inmum 0 ( x X : x 0). Edellä kuvatun ehdon mukaisesti siis X Y mikäli X on ala- ja ylärajaltaan Y :n vastaavia pienempi. Esimerkiksi pätee siis [0, 1; 0, 5] [0, 2; 0, 6], mutta mikäli jälkimmäisen välin yläraja olisi 0,4, järjestystä ei voitaisi ilmaista. Luottamusarvojen joukkoa T ei ole järjestysten määrittämistä lukuunottamatta rajoitettu. Se voisi siis olla yksiulotteisten arvojen joukko T = {tuntematon, matala, korkea} tai koostua viisiulotteisista vektoreista, kunhan näille on määritetty vaaditut järjestykset ja. Luvun 2 sähköinen lompakko -esimerkissä tällainen joukko saadaan pareista (m, n), missä m on positiivisten ja n negatiivisten kokemusten lukumäärä. Luottamuksen määrän mukainen järjestys saadaan määrittämällä (m 1, n 1 ) (m 2, n 2 ) jos ja vain

jos m 1 m 2 ja n 1 n 2, eli yhtäaikaisesti hyviä kokemuksia on enemmän tai yhtä monta ja huonoja vähemmän tai yhtä monta. Tiedon määrän mukainen järjestys määritellään siten, että jos luottamusarvosta (m 1, n 1 ) päästään arvoon m 2, n 2 ) saamalla lisää kokemuksia (eli m 1 m 2 ja n 1 n 2, jolloin hyvien ja huonojen kokemusten summa pysyy samana tai kasvaa), on tiedon määrä tällöin kasvanut: (m 1, n 1 ) (m 2, n 2 ). Kuva 2 selkeyttää järjestysten eroa. Tiedon määrä kasvaa siinä alhaalta ylöspäin merkittyjä polkuja pitkin pohja-arvosta (0, 0). Samalla korkeudella olevat arvot (0, 2) ja (2, 0) eivät ole vertailukelpoisia tämän järjestyksen mukaan. Luottamuksen määrä kasvaa vasemmalta oikealle; tässä järjestyksessä (0, 2) (2, 0), mutta kohdakkain olevat arvot (0, 1) ja (1, 2) eivät ole vertailukelpoisia, vaikka (0, 1) (1, 2). Luottamusarvoja päivitetään omakohtaisten kokemusten ja suositusten perusteella. Suositukset ovat muodoltaan kokemuksen kaltaisia. Kokemus edustaa toiminnan todellista lopputulosta, ja sitä voidaan verrata riskiarvion perusteella odotettuun lopputulokseen. Mikäli tulos oli odotettua parempi, sillä on positiivinen vaikutus luottamusarvoon sen edustaman luottamuksen määrän suhteen. Jos se taas oli odotettua huonompi, vaikutus luottamusarvoon on negatiivinen. Ennusteen mukaisessa tilanteessa voidaan luottamuksen määrän muutoksen sijaan vain katsoa luottamusarvon sisältävän aiempaa enemmän tietoa. Kokemusten lukumäärään perustuva (m, n)-luottamusarvo muuttaa joka askeleella sekä tiedon että luottamuksen määrää. 7 4.2 Riskin tietomalli Riskiarvio tehdään kullekin toiminnolle ja sen jokaiselle erilaiselle riskiltään erilaiselle lopputulokselle. Lisäksi arvio riippuu toimijalle lasketusta luottamusarvosta, ja sitä päivitetään kokemusten perusteella. Lopullinen riskiarvio on siis useiden tekijöiden summa. Riskiarviot koostuvat todennäköisyysjakaumista menetysten tai saavutettujen etujen suhteen. Tietyllä luottamusarvolla pyritään ennustamaan tietynlaista käytöstä, joten eri seurausten tarkat todennäköisyysjakaumat riippuvat luottamusarvosta. Epäluotettavaksi arvioidulla toimijalla menetykset arvioidaan todennäköisemmiksi, ja hyvä lopputulos epätodennäköisemmäksi. Monimutkaisempi luottamusarvo voi myös vastata riskiarviota, jossa esimerkiksi muutaman euron ostoksissa huijaaminen on varsin epätodennäköistä, mutta tietyn rahamäärän ylittyessä todennäköisyys nousee huomattavasti korkeammaksi. Tähän eri vaikutusten todennäköisyysjakaumaan (cost(benet) propability density function, cost-pdf) voidaan sijoittaa esimerkiksi ostoksen hinta ja saada todennäköisyys sille, että ostaja maksaa väärällä rahalla, jolloin toiminnon hinnaksi ja siten menetyksen suuruudeksi kauppiaan kannalta tulee ostoksen hinta. Lopullinen riskiarvio yhdistää toiminnan eri lopputuloksille tehdyt todennäköisyysjakaumat. Itse luottamuspäätös tehdään tämän lopullisen arvion perusteella. Kuvassa 3 sivulla 8 on esitetty yhden luottamuspäätöksessä arvioitavan lopputuloksen

8 Kuva 3: Luottamus- ja riskitietojen käyttö päätöksenteossa [CGS + 03]. Eri lopputulosten todennäköisyysarviot yhdistetään yhdeksi todennäköisyysjakaumaksi, jonka perusteella päätös tehdään.

9 Kuva 4: Riskianalyysiä: arvioiden yhdistäminen [CGS + 03]. tilanne. Toiminto parametreineen määrittää kullekin erilaiselle lopputulokselle tietyn vaikutusten todennäköisyysjakaumien perheen, josta arvioidun luottamusarvon perusteella valitaan sopivin. Valittu todennäköisyysjakauma välitetään analysoijakomponentille, joka yhdistää sen ja muiden lopputulosmahdollisuuksien vaikutusten todennäköisyysjakaumat yhdeksi. Kuva 4 näyttää esimerkin tällaisesta yhdistämisestä. Lopuksi toiminnon toteutumista tarkkaillaan, mikä taas vaikuttaa välillisesti luottamusarvon laskentaan ensi päätöskerralla. Sähköinen lompakko -esimerkissä lopputuloksia oli vain kaksi erilaista, joko rahat menetettiin tai ne saatiin. Tässä yhdistämisessä on kolme eri lopputulosta, jotka liittyvät puhelinmuistion tietojen päivitykseen. Saadut tiedot voivat olla oikeita, jolloin lopputulos on totta kai myönteinen. Toisaalta ne voivat olla vääriä, mistä seuraa menetyksiä lähinnä ajan hukkaamisen mielessä. Riskimallissa erilaiset menetykset, esimerkiksi rahalliset, uskottavuuteen liittyvät, ajanhukka ja jopa ihmishenkien menetys oletetaan nähtävästi kaikki voitavan ilmaista yhdellä asteikolla, joka voidaan siten tulkita esimerkiksi rahalliseksi menetykseksi. Tiedot voivat olla vääriä kahdesta eri syystä, mikä nostaa päivitystoiminnon lopputulosten määrän kolmeen kahden sijaan. Ne voivat olla tahallisesti väärin ilmoitettuja (kuvassa malicious), jolloin menetykset ovat todennäköisesti suuremmat kuin jos tiedot ovat vain vanhentuneet (out of date). Vanhentuneet tiedot voivat yhä johtaa oikeille jäljille, jos niiden päästä löytyy esimerkiksi nauhoitettu viesti, joka kertoo numeron muuttuneen. Sen sijaan tahallisesti väärin ilmoitetut tiedot tuskin tukevat tällaista jäljitystä, jolloin ajanhukka on suurempi. Esimerkin kuvan 4 perusteella voidaan arvioida, että käyttäjä, johon arviot liittyvät, antaa melko todennäköisesti oikeita tietoja, mutta ilmeisesti myös silloin tällöin tiedot ovat vanhentuneita. Sen sijaan tahallisesti väärien tietojen antaminen on arvioitu varsin epätodennäköiseksi, joten tätä lopputulosta tukevia kokemuksia on

10 ainakin tämän käyttäjän kohdalla ollut varsin vähän tai ei lainkaan. Sähköisen lompakon esimerkissä riskin voidaan katsoa olevan esimerkiksi lineaarisesti riippuvainen ostoksen hinnasta. Tällöin toiminnon `osto' parametri `rahamäärä' valitsee tai luo todennäköisyysjakaumien joukon, joissa on arvatenkin suurin todennäköisyys juuri ostoksen hinnan kokoisessa menetyksessä tai voitossa. Menetyksen ja voiton välinen todennäköisyys puolestaan riippuu luottamusarvosta. Aiemmin todettiin tässä esimerkissä käytettävän luottamusarvoja (m, n), jotka kertovat hyvien ja huonojen kokemusten määrän. Menetyksen todennäköisyyden voidaan katsoa olevan esimerkiksi huonojen kokemusten määrä jaettuna kaikkien kokemusten määrällä, eli n/(m + n). Tällöin tulee erikseen määritellä, että tuntemattoman käyttäjän tapauksessa, kun luottamusarvo on (0, 0) ja jakajan arvoksi tulee 0, menetyksen todennäköisyys olisi esimerkiksi 0,5. Voitto on tällöin lähes komplementtitapahtuma, jonka todennäköisyys olisi 1 (n/(m+n)). Esimerkkijärjestelmä sallii kuitenkin myös pienen mahdollisuuden sille, että maksusta vain osa on väärennetty, joten tämä on lopulta vain karkea arvio todennäköisyysjakauman keskeisille osille. Karkeudesta huolimatta esimerkki havainnollistaa sitä, kuinka todennäköisyysjakaumasta saadaan luottamusarvon avulla yksittäinen todennäköisyys esimerkiksi menetykselle. Tämän arvon avulla voidaan tehdä luottamuspäätös esimerkiksi yksinkertaisesti vertailemalla sitä jonkinlaiseen kynnysarvoon, joka ilmaisee siedettävän menetyksen todennäköisyyden. Mikäli menetyksen todennäköisyys ylittää tämän kynnysarvon, päätös on kielteinen. Lisäksi tämän kynnysarvon ja myönteisen päätöksen kynnysarvon välissä voi olla harmaa alue, jolloin luottamuksenhallintajärjestelmä palauttaa vastaukseksi en tiedä. 5 Pohdintaa SECURE on luottamuksenhallinnan alueella uraauurtava projekti laajuutensa ja vaikean ympäristön valinnan ansiosta. Tunnistamisen hankaluus aiheuttaa muun muassa silloin, kun yhden toimijan on mahdollista esiintyä suurena toimijoiden joukkona (ns. Sybil-hyökkäys): tällöin luottamuksen siirrettävyys esimerkiksi suositusten avulla on uhattuna. Luottamuksenhallinta on huomattava askel eteenpäin pääsynhallinnan lähentämiseksi ihmisen toimintatapoihin. Siinä missä perinteinen pääsynhallinta perustuu kertapäätöksiin, luottamuksenhallinta tuo mukaan päätöksen jälkeisen tarkkailun, joka voi myös vaikuttaa tulevaisuuden päätöksiin. Lisäksi luottamuksenhallinta, yhdistettynä jonkinlaiseen mainejärjestelmään, voi saada kokemuksia myös ympäristöstä. Tämä tieto vastaa osin yleisimmillään ihmisyhteisöissä kulkevia juoruja, joten itse tiedon luotettavuuden arviointi on myös tärkeää. SECURE on kehittänyt projektin aikana järjestelmän, joka perustuu tarkalle luottamuksen formalismille. Tämä lisää yksiselitteisyyttä järjestelmän arvioimiseksi. Luottamustiedon epävarmuuden esittäminen tietomallissa on vahvassa yhteydessä projektin ympäristön valintaan; tämä vaikuttaa olevan yksi SECUREn vahvuuksista

verrattuna moniin muihin järjestelmiin vastaavanlaisessa ympäristössä. Projekti korostaa luottamustietojen puutteellisuuden kanssa selviämisen tärkeyttä. Tässä kontekstissa on hämmentävä valinta perustaa päätökset vastaavasti hyvin tarkalle analyysille kunkin toiminnon huonojen ja hyvien lopputulosten vaikutuksista. Artikkeli ei ota kantaa siihen, kuka tämän analyysin toteuttaa ja miten. Vaikuttaisi siltä, että tällainen järjestelmä olisi jokseenkin raskas toteuttaa jatkuvasti muuttuvien sovellusten päälle. Esimerkiksi kämmenmikrojen toimintojen määrä todennäköisesti vaihtelee fyysisiä rajoituksia lukuunottamatta melkoisesti asennettujen ohjelmistojen perusteella. Järjestelmän on herätettävä tiettyä luottamusta myös käyttäjässään, jotta tämä haluaisi delegoida luottamuspäätöksensä järjestelmälle. Tämän luottamuksen herättämisessä käyttöliittymä on keskeisessä roolissa: sen tulisi olla toisaalta selkeä ja ennustettavan oloinen, ja toisaalta vakuuttaa käyttäjä siitä, että järjestelmä itse ei ole murrettavissa. Hyväkään formalismi ei välttämättä taivu ymmärrettäväksi tai käytännölliseksi käyttöliittymäksi. Odottavatko luottamuksenhallintajärjestemän kehittäjät, että käyttäjätai edes sovelluskehittäjä, jonka ei varmastikaan ole hyvä tehdä kaikkia valintoja käyttäjiensä puolestaanalysoi kaikkien suojattavien toimintojen vaikutukset itse voidakseen automatisoida päätöksiä kuten sallinko ohikulkijan PDA:n päivittää osoitetietojani? Entä ymmärtääkö peruskäyttäjä vaikutusten todennäköisyysarviota, ja olisiko jonkinlainen reaaliluvuksi tai muuksi hieman yksinkertaisemmaksi arvoksi latistaminen toisaalta mahdollista ja toisaalta hyödyksi? Asetusten ongelma toistuu yleisemmällä tasolla. Älykkäiden luottamuspäätösten tekeminen vaatii paljon tietoa ja personoinnin mahdollisuuksia, mutta omien sopivien asetusten löytäminen jokaiselle itseään suojaavalle älylaitteelle lienee ainakin valtaosalle käyttäjistä jopa ylitsepääsemättömän vaikeaa. Pitkälle viety yksinkertaistaminen ja esimerkiksi toimintojen ryhmittely merkityksettömiin ja riskialttiisiin sekä ryhmäkohtaiset asetukset helpottavat käyttäjän ongelmaa, mutta vähentävät samalla luottamuksenhallintajärjestelmän hyötyä verrattuna yksinkertaisempiin ratkaisuihin. Jos käyttäjä tarvitsee ulkopuolisen konsultin järjestelmän asetusten löytämiseksi, syntyvä käyttökynnys voi rajata luottamuksenhallintajärjestelmät käytännössä muiden kuin suurten yritysten tarjoamien erikoistuneiden (vähätoimintoisten) palveluiden ulkopuolelle, Entä luottamuksenhallinnan lupaus olla nykyjärjestelmiä dynaamisempi? Tähän vaatimukseen kuuluu läheisesti luottamuksen päivittyminen omien ja/tai muiden toimijoiden kokemusten perusteella. Mutta miten kokemuksia kerätään? Verkkohuutokauppa ebayn [eba05] käyttämän mainejärjestelmän kaltaiset ratkaisut käyttävät ihmisten antamaa palautetta, jota ihmiset arvioivat itse luottamuspäätöksiä tehdessään. Arvioinnin tarkkuus vaihtelee sen mukaan, miten suuren riskin käyttäjä on ottamassa ja toisaalta sen mukaan, miten kokenut hän on mainetta arvioimaan tarkistaako hän esimerkiksi positiivisten palautteiden lukumäärän lisäksi sen, miten luotettavalta vaikuttavat käyttäjät ovat palautetta antaneet. Ihmisiin tukeutuminen ei luottamuspäätösten yleistyessä lopulta riitä, vaan kokemuksen keruu sekä maineen tai luottamuksen arviointi pitäisi voida molemmat automatisoida. 11

12 Kokemusta kerätään tarkkailemalla sallitun toiminnon lopputulosta. Sovellusten ja siten hyökkäysten erilaisuuden takia suuret läpimurrot tarkkailun alalla saattavat vaatia jo melkoisia edistysaskeleita tekoälytutkimuksessa. Millainen tarkkailun laatu on realistisesti saavutettavissa ja onko se riittävää, vai tarvitsemmeko välttämättä ihmisekspertin apua? Yleisin automaattisen tarkkailun väline tällöä hetkellä lienee tunkeutumisenestojärjestelmä (Intrusion Detection System, IDS). Nykyiset järjestelmät osaavat esimerkiksi laskea tietyt IP- tai TCP/UDP-kehyksen ominaisuudet täyttävät verkkopaketit tai etsiä kaavavamaisuuksia jonoista palvelukutsuja käyttöjärjestelmälle. Ne eivät kuitenkaan sovellu lainkaan esimerkiksi vanhentuneiden yhteystietojen saamisen havaitsemiseen, tai edes korkeamman tason protokollassa tarkistamaan, että maksu-viesti seuraa osto-viestiä. Maksu- ja ostoviestit voivat lisäksi olla sovellustasolta lähtien salattuja, jolloin ainakaan verkkotason IDS ei voi edes erottaa niitä toisistaan. Sovelluksen toiminnan ymmärtäminen omalla tasollaan ja tämän ymmärryksen liittäminen tarkkailuun sovellustason tietomurtohälyttimissä on vielä jokseenkin uusi lähestymistapa. Välillisen kokemuksen keruu kolmansien osapuolten omaan tai jälleen välilliseen kokemukseen perustuvien suositusten avulla on myös haastava aihe. Ihmiset eivät ole erityisen rationaalisia tässä suhteessa, vaan saattavat uskoa lähes mitä tahansa, jos lähde tuntuu riittävän vakuuttavalta. Tähän tuntemukseen vaikuttavat asiat eivät välttämättä liity lainkaan lähteen tiedon määrään tai hyviin aikomuksiin, vaan esimerkiksi lähteen ulkonäköön, ääneen tai käsialaan, sanavalintaan tai vaikkapa siihen, onko hän esiintynyt edukseen jossakin televisio-ohjelmassaroolihahmona tai itsenään. Mikäli tietokone ottaa mallia ihmisistä, se on myös vähintään yhtä helposti huijattavissa. Toisaalta tämä voi olla myös itse järjestelmälle eduksi; mikäli ihmistä älykkäämmäksi tarkoitetun algoritmin tuloksena syntyy usein päätöksiä, jotka tuntuvat käyttäjän kannalta olevan ristiriidassa tämän omien tuntemusten kanssa, käyttäjä saattaa luopua järjestelmästä ellei ymmärrä sen toimintaperiaatteita. Ihmisen toimintaa läheisesti mallintavasta järjestelmästä kehittyy helposti monimutkainen. Järjestelmän toiminnan selkeyttämiseksi hyvät esimerkit ovat tarpeen. Kämmenmikro- ja sähköinen lompakko -esimerkit tuovat kukin tavallaan järjestelmän yksityiskohtia esiin, mutta niiden heikkoutena on esimerkkien ainoan päällekkäisyyden, vaikutusten todennäköisyysarvioiden, esittäminen kahdella eri tavalla. Kämmenmikroesimerkissä funktiota kuvataan yksinkertaisen todennäköisyysjakauman avulla, mikä sopii yhteen yleisen kuvailun kanssa, mutta jonka käytettävyyttä hinnan sijoituksen avulla myöhemmän esimerkin tapaan lukija jää epäilemään. Sähköinen lompakko -esimerkissä todennäköisyysjakauman sijaan pääosassa on riskin suuruutta reaaliarvona ilmaiseva funktio, josta annetaan kaksi liikkuvan rahamäärän myötä rajatta kasvavaa esimerkkiä. Lisäksi esimerkki tuntuu perustuvan oletukselle, että käytössä on järjestelmä jossa sähköisen rahan väärentäminen on niin tavallista, että yksittäisten toimijoiden tasolla kannattaa laskea väärennöksillä ja oikealla rahalla maksettuja toimintojamikä tästä järjestelmästä tekee niin houkuttelevan väärentää, ja eikö ongelmia ole mahdollista korjata itse järjestelmässä? Vastaavasti toimintaperiaatteeltaan jokseenkin samankaltainen Suomessa käytetty Avant-korttiraha on ollut toiminnassa lähes kymmenen vuotta. Avant-järjestelmää

ylläpitävä ja kehittävä Automatia Pankkiautomaatit Oy kehuu sen säästyneen väärennösrikoksilta toimintansa ajan [Ava05]. Kolmas esimerkki, korttipeli ad hoc - ryhmässä, on suhteellisen pinnallinen kuvaus kehitteillä olevasta esimerkkisovelluksesta ja sen asettamista vaatimuksista luottamuksenhallinnan toteuttamiseksi sovelluksessa. 13 6 Yhteenveto Uusissa liikkuvan tietojenkäsittelyn sovelluksissa tarvitaan mitä moninaisempien laitteiden yhteistoimintaa. Ympäristöön liittyy paljon epävarmuutta ja riskejä, mikä vaikeuttaa tasapainon löytämistä kunkin autonomisen järjestelmän itsesuojauksessa: täysin suljettu järjestelmä on varsin turvallinen, muttei välttämättä kovin mielenkiintoinen tai tarkoituksenmukainen. Luottamuksen käsitteen avulla voidaan järkevöittää riskinottoa mahdollistamalla se tilanteissa, joissa aiemman kokemuksen perusteella menetysten todennäköisyys on riittävän pieni. Edellä on kuvattu SECURE-projektin kehittämä luottamuksenhallintajärjestelmä, luottamuksen ja riskin tietomallit ja esimerkkejä, joiden pohjalta järjestelmän arviointi mahdollistuu. Kuvatuista järjestelmistä johdetut yksityiskohtaisemmat, selventävät esimerkit seuraavat päälähdettä [CGS + 03] yleisen toiminnan kuvailua löyhemmin, minkä tavoitteena on ollut ensisijaisesti selkeys sekä järjestelmän mahdollisuuksien ja rajojen tarkempi esiintuominen. Vuodesta 2002 käynnissä ollut SECUREprojekti on tuottanut yli kolmekymmentä julkaisua [SEC05], joiden keskeisistä osista päälähde toimii eräänlaisena tiivistelmänä. Selvennykset tuntuvat siten olevan monin paikoin tarpeen. Lähteet Ava05 Avant-korttirahan esittelysivu, 2005. http://www.avant.fi. [25.4.2005] CGS + 03 Cahill, V., Gray, E., Seigneur, J.-M., Jensen, C., Chen, Y., Shand, B., Dimmock, N., Twigg, A., Bacon, J., English, C., Wagealla, W., Terzis, S., Nixon, P., Serugendo, G. D. M., Bryce, C., Carbone, M., Krukow, K. ja Nielson, M., Using trust for secure collaboration in uncertain environments. Pervasive Computing, 2,3(2003), sivut 5261. URL http://ieeexplore.ieee.org/iel5/7756/27556/01228527.pdf. eba05 ebay-verkkohuutokauppa, 2005. http://www.ebay.com/. [17.4.2005] MC96 McKnight, D. H. ja Chervany, N. L., The meanings of trust. Tekninen raportti, University of Minnesota, MIS Research Center, 1996. URL http://misrc.umn.edu/workingpapers/fullpapers/ 1996/9604_04010%0.pdf. Taulukot liitteenä verkkoversiossa.

14 RZFK00 SEC05 SFJ + 03 WCE + 03 Resnick, P., Zeckhauser, R., Friedman, E. ja Kuwabara, K., Reputation systems. Communications of the ACM, 43,12(2000), sivut 4548. URL http://doi.acm.org/10.1145/355112.355122. SECURE-projektin sivut Trinity College Dublinissa., 2005. http:// www.dsg.cs.tcd.ie/index.php?category_id=206. [17.4.2005] Seigneur, J.-M., Farrell, S., Jensen, C. D., Gray, E. ja Yong, C., End-to-end trust starts with recognition. Tekninen raportti, Trinity College Dublin, 2003. URL http://www.cs.tcd.ie/publications/ tech-reports/reports.03/tcd%-cs-2003-05.pdf. Wagealla, W., Carbone, M., English, C., Terzis, S. ja Nixon, P., A formal model on trust lifecycle management. Teoksessa Workshop on Formal Aspects of Security and Trust (FAST2003) at FM2003, osa IIT TR-10/2003, IIT-CNR, Italy, syyskuu 2003, sivut 184195. URL http: //www.iit.cnr.it/fast2003/fast-proc-final.pdf (TR-10/2003).