1 Johdanto

Internetin yleistymisen myötä tietoverkot ovat avanneet uusia mahdollisuuksia erilaisten palveluiden tarjoamiseen yhä laajemmalle käyttäjäkunnalle. Varsinkin elektronisen kaupankäynnin yleistymisen myötä on noussut esiin kysymyksiä maksutapojen turvallisuudesta tietoverkossa. Uhkana pidetään riittävän tietoturvan puuttumista, joka onkin suurimpia hidasteita verkkokaupan yleistymisessä.

Tietoturva voidaan luokitella puolustavaan eli defensiiviseen ja hyökkäävään eli offensiiviseen tietoturvaan. Perinteisesti tietoturva on ollut defensiivistä, jossa tietojärjestelmiä ja käyttäjiä on haluttu suojata ulkomaailmalta. Offensiivisissa ratkaisuissa tietoturva on rakennettu palvelujen ja sovellusten sisään valmiiksi. Tietoturvan toteutusratkaisut perustuvat kryptografiaan. Kryptografia tarkoittaa tietoturvapalveluihin liittyvien matemaattisten menetelmien tutkimusta [Kerttula, s. 23].

Tietoturvapalveluita ovat mm. tiedon tai siirron luottamuksellisuuden, tiedon eheyden, olion autenttisuuden tai tiedon alkuperän autenttisuuden takaaminen. Verkon liikenteen suojaaminen edellyttää kryptomekanismien sijoittamista jonnekin verkkoon. On erityisen tärkeää pystyä määrittelemään sopivat tietoturvatarpeet tapauskohtaisesti. Tämä edellyttää mm. liitäntöjen ja informaation kannalta erilaisen verkkoliikenteen tunnistamista.

Tietoturvaa suunniteltaessa on huomioitava myös tietoturvaa edistävät verkkolaitteet, kuten palomuurit. Palomuureilla pyritään estämään luvaton pääsy verkkosegmenttiin, kuten yrityksen intranetiin. Palomuurin tehtävänä on siis suorittaa pääsynvalvontaa ja tapahtuman seurantaa. Pääsynvalvontaa voidaan suorittaa sekä sisään- että ulospäin.

Palomuurit eivät kuitenkaan sellaisenaan pysty torjumaan hyökkäyksiä verkon sisältä päin. Useat tietoturvarikkomukset tapahtuvatkin organisaation sisältä. FBI:n (Federal Bureau of Investigation) ja CSI:n (Computer Security Institute) laajan tutkimuksen mukaan tietoturvarikkomuksista yli 50 % tuli sisältäpäin. Aina ei myöskään arkaluontoisen informaation piilottaminen suljettuun verkkoon ole mahdollista (esim. verkkopankit). Tosiasia on, että kaikki tietoverkot ovat alttiita tietoturvarikkomuksille. Todellinen tietoturvallisuus vaatii tasapainon saavuttamista tietoturvatavoitteiden, uhkien ja kustannusten välillä.

Tietoverkkojen yleistyttyä myös hajautetut sovellukset ovat yleistyneet. Tämän päivän tavoitteita sovelluskehityksessä onkin toimintojen ja hallinnan keskittäminen sekä sovelluksen arkkitehtuurista riippuen ns. liiketoimintalogiikan (engl. business logic) hajauttaminen. Tunnetuin esimerkki lienee kolmikerrosarkkitehtuuri (engl. 3-tier), jossa on esimerkiksi WWW-pohjainen käyttöliittymä, WWW-palvelin sekä tietokanta-palvelin. Kullakin kolmella kokonaisuudella on oma ohjelmisto, jolla tarjotaan palveluja tai käytetään niitä.

Sovelluksen käyttötarkoitus saattaa edellyttää myös tiedon siirron salaamista hajautetuissa järjestelmissä. Edellisen esimerkin tapauksessa käyttötarkoituksesta ja suoritusympäristöstä riippuen saatettaisiin tiedon salausta tarvita kaikkien kerrosten välillä (käyttöliittymästä WWW-palvelimelle ja WWW-palvelimelta tietokantapalvelimelle) tai esimerkiksi vain käyttöliittymän ja WWW-palvelimen välillä. Hajautetuissa järjestelmissä tietoturva-ajattelu voi mennä tästä vielä paljon pitemmälle, kun syntyy tarve autentikoida etäkutsuja suorittavia oliota.

Tutkielmassa esitellään yleisimmät hajautusmenetelmät toimintaperiaatteineen sekä yleisimmät hajautusmenetelmiin soveltuvat tietoturvaratkaisut. Näistä tietoturvaratkaisuista esitellään myös lyhyesti yleisimmin käytetyt algoritmit yksityiskohtiin puuttumatta. Kaikkia standardeissa mainittuja algoritmeja ei käydä läpi, sillä tämän tutkielman tarkoituksena on havainnollistaa tietoturvamenetelmiä hajautetuissa järjestelmissä, eikä esitellä tietoturva-algoritmeja. Menetelmiä lähestytään Java-kielen näkökulmasta johtuen käsiteltävästä RMI-menetelmästä, joka on suunniteltu ainoastaan Java-ympäristössä toimivaksi. Tutkielmassa ei käsitellä erilaisten verkkoinfrastruktuurien tarjoamia tietoturvamahdollisuuksia, vaan keskitytään suoraan hajautusmenetelmiin liittyviin tai niihin kohdistuviin yleisimpiin menetelmiin.

Luvussa 2 esitellään lyhyesti yleisempiä tiedonsalaus- ja autentikointialgoritmeja. Seuraavassa luvussa käsitellään näihin algoritmeihin perustuvia salausmenetelmiä. Luvussa 4 esitellään yleisimpiä hajautusmenetelmiä ja niiden tietoturvaratkaisuja sekä niihin sovellettavia tietoturvamenetelmiä.

2 Tiedon salausmenetelmät

Datasanomia salataan nykyisin tunnetuilla algoritmeilla, kuten DES ja IDEA. Jos algoritmit ovat turvallisia, näillä salatut viestit ovat yhtä salaisia kuin niiden avaimet [Kerttula, s.63]. Algoritmien turvallisuuden todistaminen onkin yksi kryptografian tärkeimmistä ongelmista. Hyvän salausjärjestelmän tulee toteuttaa ns. Kerckhoffin periaate (Auguste Kerckhoff, 1835-1903), jonka mukaan järjestelmä on varma, vaikka kaikki sen salaus- ja purkuprosessien yksityiskohdat julkistettaisiin lukuun ottamatta salaista avainta.

Kryptografiset tuotteet rinnastetaan länsimaissa usein aseisiin ja niihin kohdistuu tiukkoja vientirajoituksia. Vientirajoitukset määritellään yleensä avaimen pituuden mukaan. Tavallisesti maasta voidaan viedä ainoastaan 40 bitin pituiset avaimet, jotka voidaan kohtuullisella laskentateholla murtaa muutamassa tunnissa.

Tässä luvussa käsitellään lyhyesti luvuissa 3 ja 4 esiteltyjen salausmenetelmien käyttämiä algoritmeja. Lohkosalaajan toiminta perustuu joko salattavien lohkojen korvaamiseen toisilla (engl. substitution) tai lohkojen sekoittamiseen (engl. transposition). Jonosalaajat voivat olla bitti- tai merkkipohjaisia. Jonosalaajan ei tarvitse paloitella sanomaa lohkoihin lohkosalaajan tapaan ja jonosalaaja voi toimia myös reaaliaikaisesti. Luku perustuu lähteeseen [Kerttula].

2.1 Salaisen avaimen menetelmät

Salaisen avaimen menetelmissä toiminta-ajatuksena on sopia kahden osapuolen välille tiedonsalaukseen käytettävä avain. Salaisen avaimen menetelmiä kutsutaan myös symmetrisiksi avainmenetelmiksi, koska molemmat osapuolet käyttävät salaamiseen ja salauksen purkamiseen samaa avainta. Ongelmana näissä menetelmissä on avaimen sopimiseen tarvittavan kommunikaation salassapito.

2.1.1 DES (Data Encryption Standard)

DES on yleisin salaisen avaimen menetelmistä. Algoritmi otettiin käyttöön vuonna 1977 Yhdysvaltain hallituksen toimesta. DES voidaan toteuttaa mikropiirille, joten se on käyttökelpoinen myös suurissa tietoliikennejärjestelmissä.

DESin salaus- ja purkualgoritmit on julkistettu ja siitä on myös ohjelmistototeutuksia. Lyhyen avaimensa (56 bittiä) vuoksi DES alkaa olla kuitenkin jo vanhentunut ja se on jo pystytty murtamaan. Vuonna 1998 DES Challenge II-2 -haaste ja 10 000 dollarin palkinto DES-algoritmin murtamisessa voitettiin 250 000 dollarin laitteistolla, joka kävi läpi 90 miljardia avainta sekunnissa. Aikaa murtamiseen kului 56 tuntia. IETF (Internet Engineering Task Force) ei enää tue DES-algoritmia Internet-standardeissaan. Tästä huolimatta se tulee olemaan vielä käytössä vuosia laajan levinneisyytensä vuoksi.

DES-algoritmia käytetään eri toimintatiloissa (engl. mode) sovelluksesta ja tietoturvatarpeista riippuen. DESin neljä tärkeintä toimintatilaa ovat ECB, CBC, CFB ja OFB. ECB:ssä (Electronic Codebook) DES on muistiton lohkosalaaja ja se on DES-algoritmin suoraviivaisin käyttötapa. ECB on ideaalinen lyhyiden viestien, kuten DES-avainten salaamiseen.

CBC:n (Cipher Block Chaining) toiminta-ajatuksena on salasanoman ketjutus ja se toimii takaisinkytkentäperiaatteella. Moodi poistaa ECB:n heikkoudet pitkien, rakenteisten sanomien kohdalla. Haittana CBC:ssä on avaimen pituus, joka on vain 56 bittiä. CBC:tä käytetään yleiskäyttöisessä lohkosalauksessa ja autentikoinnissa.

CFB (Cipher Feedback) on itsesynkronoituva jonosalaaja, jota käytetään yleiskäyttöisessä jonosalauksessa ja autentikoinnissa. Haittana tässäkin toimintatilassa on 56 bitin mittainen avain.

OFB (Output Feedback) on samankaltainen kuin CFB. Sitä käytetään jonopohjaisessa siirrossa kohinaisissa kanavissa.

2.1.2 3-DES

3-DES eli Triple-DES tarkoittaa kolmen DES-salaajan käyttöä peräkkäin ja se voidaan implementoida eri tavoilla. DES-EEE3 -menetelmässä tehdään kolme salausta peräkkäin kolmella eri avaimella, DES-EDE3:ssa tehdään salaus-purku-salaus -operaatio kolmella eri avaimella ja DES-EEE2- sekä DES-EDE2 -menetelmät vastaavat edellisiä, mutta ensimmäinen ja kolmas DES käyttää samaa avainta. Mainittakoon, että DES-EDE -algoritmin nopeus on noin puolet DES algoritmin nopeudesta, eikä kolmasosa, johtuen implementoinneissa hyödynnettävistä DESin ominaisuuksista.

2.1.3 RC2 ja RC4

Ron Rivest on yksi tunnetuimpia kryptograafikoita maailmassa. Hänen kehittämät RC2- ja RC4-algoritmit ovat salaisia, muuttuvan pituisella avaimella toimivia algoritmeja. RC2 on lohkosalaaja, jonka tarkoituksena oli korvata DES. RC4 on puolestaan jonosalaaja.

RC2- ja RC4-algoritmeja saadaan viedä USA:sta vain, jos niiden avainten pituus on korkeintaan 40 bittiä. RC4-40 algoritmi (avain 40 bittiä) on pystytty murtamaan alle kahdeksassa tunnissa. RC2- ja RC4-algoritmeja käytetään lukuisissa tuotteissa, joita viedään USA:sta. Näitä ovat esimerkiksi SSL sekä S-HTTP. Algoritmien yksityiskohtia ei ole julkistettu, joten niiden luotettavuutta ei pidetä yhtä hyvänä kuin DES-algoritmin. Ei kuitenkaan ole tiedossa, että RC2- ja RC4 -algoritmit olisivat haavoittuvia mihinkään hyökkäykseen.

2.1.4 Blowfish

Blowfish on Bruce Schneierin vuonna 1993 suunnittelema algoritmi. Siinä käytetään muuttuvanpituista avainta, joka on vähintään 32 ja korkeintaan 448 bittiä. Se on 64 bitin lohkosalaaja, joka on kehitetty nimenomaan 32-bittisille tietokoneille. Algoritmi on huomattavasti DES-algoritmia nopeampi ja sitä pidetään varmana ja erittäin hyvänä algoritmina. Blowfish-algoritmi on julkinen.

Ennen varsinaista kryptausta joudutaan kuitenkin suorittamaan suhteellisen monimutkainen alustusvaihe. Algoritmi jakaantuu siis kahteen vaiheeseen: avaimen laajennukseen (engl. key expansion) ja tiedon salaukseen. Avaimen laajennuksessa korkeintaan 448 bitin avain konvertoidaan aliavaintauluiksi (engl. subkey arrays).

Kryptauksessa iteroidaan yksinkertaista kryptausfunktioita 16 kertaa. Kukin iterointikierros sisältää avainriippuvaisen permutaation sekä avain- ja data-riippuvaisen korvausoperaation. Kaikki algoritmin operaatiot ovat XOR-operaatioita tai lisäyksiä 32 bitin sanoille. Iteraatiossa käytetään alustusvaiheessa muodostettuja aliavaimia.

Blowfish soveltuu parhaiten tilanteisiin, joissa avain ei muutu usein, kuten tietoliikenneyhteyksillä ja tiedostojen salauksessa.

2.2 Tiivistefunktiot MD5 (Message Digest) ja SHA (Secure Hash Algorithm)

MD5 ja SHA ovat ns. hash-funktiota, jotka ovat keskeisessä asemassa digitaalisissa allekirjoituksissa ja datan eheyden tarkastamisessa. Hash-funktiot, eli tiivistealgoritmit eivät tarvitse erillistä avainta sanoman tiivistämiseen.

MD5 on RC2- ja RC4-algoritmien tapaan Ron Rivestin suunnittelema. MD5 on kehitetty 1990-luvun alussa ja se on nykyään mukana lähes kaikissa kryptotuotteissa. MD5 on nopea, yksinkertainen ja turvallinen. Tiivisteen pituus on 128-bittiä, jota jotkut pitävät liian lyhyenä.

SHA puolestaan tuottaa 160 bitin tiivisteen, joten sitä voidaan pitää MD5:tä turvallisempana. SHA algoritmi on USA:n NIST:n (National Institute of Standards and Technology) 1990-luvun alussa kehittämä ja sitä käytetään mm. USA:n hallinnon digitaalisen allekirjoituksen DSA-standardissa. SHA -algoritmille ei tunneta kryptograafista hyökkäystä ts. algoritmia, jolla SHA-algoritmi olisi murrettu. Näin ollen laskentatehoon perustuva raa'an voiman hyökkäys on ainoa, jolla algoritmi voidaan murtaa. Raa’an voiman hyökkäyksessä käydään läpi kaikki mahdolliset purkuavaimet. Myös SHA on yksinkertainen ja tehokas toteuttaa ohjelmistollisesti. Se on jonkin verran MD5:tä hitaampi, mutta tällä ei ole käytännön merkitystä. SHA on käytössä useissa kaupallisissa tietoturva-algoritmeissa.

2.3 Julkisen avaimen menetelmät

Julkisen avaimen menetelmät perustuvat matemaattisiin funktioihin ja matemaattisen laskennan kompleksisuuteen. RSA-, DSA- ja Diffie-Hellman -menetelmät perustuvat julkisen avaimen teknologiaan. Julkisen avaimen, eli asymmetrisen avaimen menetelmiä käytetään salaamiseen, autentikointiin ja avainten hallintaan.

Julkisen avaimen menetelmissä käytetään kahta avainta, joista toista salaamiseen ja toista purkamiseen. Näistä salausavain julkistetaan, josta seuraa myös menetelmän nimi. Menetelmässä on siis olennaista, ettei purkuavainta tunne muut kuin julkisen avaimen julkistaja. Siten ainoastaan asianosainen pystyy purkamaan salatun sanoman.

Esimerkiksi, jos Mirva haluaa lähettää Markukselle salatun viestin, etsii hän ensiksi Markuksen julkisen avaimen ja salaa sanomansa sillä. Tätä voisi verrata tilanteeseen, jossa Mirva lukitsisi kirjoittamansa viestin laatikkoon lukolla (salausavain), johon vain Markuksella olisi avain. Laatikko (eli salattu sanoma) lähetetään Markukselle, joka avaimellaan avaa laatikon (purkaa salauksen salaisella purkuavaimella) ja lukee viestin. Jos utelias postinkantaja Timo saa käsiinsä laatikon ei hän voi lukea viestiä, koska hänellä ei ole hallussaan Markuksen avainta. Edes Mirva ei voi muuttaa viestin sisältöä lukittuaan sen laatikon sisään. Timokin voi saada esteettä lukkoja, joihin Markuksella on yksilöllinen avain.

Julkisen avaimen algoritmit ovat hitaampia kuin salaisen avaimen algoritmit, eikä niitä siten yleensä käytetä itse sanomien salaamiseen. Pitkät sanomat salataankin salaisen avaimen menetelmillä, mutta itse avaimet ja allekirjoitukset salataan julkisen avaimen periaatteella.

2.3.1 Diffie-Hellman

Whitfield Diffien ja Martin Hellmanin 1976 julkistama Diffie-Hellman -avaintenjakelu on julkisen avaimen kryptografiaan perustuva algoritmi. Diffie-Hellman- eli DH-algoritmi määrittelee turvallisen mekanismin salaisen avaimen neuvotteluun. Salaisen avaimen menetelmissä ongelmana on avaimen välittäminen turvallisesti lähettäjältä vastaanottajalle. Diffie-Hellman -protokolla ratkaisee salaisen avaimen välityksen ongelman siten, etteivät osapuolet tarvitse salaista informaatiota avaimen turvalliseen välittämiseen.

Yleisen toimintaperiaatteen mukaan osapuolet A ja B sopivat aluksi kahdesta suuresta, vähintään 150 numeroisesta (eli noin 512 bittiä) kokonaisluvusta a ja b. Näiden numeroiden sieppaamisesta ei ole salakuuntelijalle mitään hyötyä, joten tätä informaatiota ei tarvitse salata. Seuraavaksi osapuolet valitsevat molemmat, toisistaan erillään, suuret luvut (n. 512 bittiä) A x:n ja B y:n, jotka osapuolet pitävät salassa. Tämän jälkeen molemmat syöttävät salaiset lukunsa (x ja y) ja edellä sovitut kaksi suurta kokonaislukua (a ja b) ennalta sovittuun eksponenttifunktioon. A saa tulokseksi luvun k ja B luvun l. Osapuolet vaihtavat saamansa tulokset avoimesti, jonka jälkeen molemmat suorittavat vastaavantyyppiset eksponenttilaskut toisiltaan saamillaan luvuilla (A luvulla l ja B luvulla k). Laskennan tuloksena molemmat saavat identtisen luvun, jota voidaan käyttää salaisena avaimena.

Diffie-Hellman -menetelmä on altis ns. middle-person –hyökkäykselle, jossa salakuuntelija C sieppaa osapuolilta A ja B julkiset luvut ja lähettää omat julkiset luvut osapuolille A ja B. Tällöin A ja C sopivat omasta salaisesta avaimesta sekä C ja B omasta. A ja B eivät siten havaitse C:n läsnäoloa. Diffie-Hellman ei näin ollen takaa osapuolten autenttisuutta.

2.3.2 RSA-menetelmä

RSA on julkisen avaimen menetelmä, jota voidaan käyttää salaukseen, digitaalisiin allekirjoituksiin ja avainten jakeluun. RSA:n ovat kehittäneet MIT:ssä Ron Rivest, Adi Shamir ja Leonard Adleman vuonna 1978.

RSA on tärkein nykyisistä julkisen avaimen menetelmistä. Se on lohkosalaaja, jossa selväkieli- ja salasanomat ovat kokonaislukuja välillä [0..n-1]. Sanoma ja sanomalohkot muutetaan kokonaisluvuiksi jollain yksikäsitteisellä tavalla. RSA-algoritmi perustuu yksisuuntaiseen funktioon. Algoritmi on julkinen ja se on esitelty myös useissa oppikirjoissa.

RSA-129 on 129-numeroinen luku, joka julkaistiin ensimmäisen kerran vuonna 1977. Huhtikuussa 1994 RSA-129 murrettiin. Tähän tarvittiin kahdeksan kuukautta. Vaikka RSA-129 murrettiin, ei tämä heikennä vielä RSA:n salaavuuden voimaa, sillä RSA-129 murtaminen vaati suunnatonta laskentavoimaa nykyisiin kaupallisiin resursseihin nähden.

2.3.3 ElGamal ja DSA (Digital Signature Algorithm)

Luvuissa 2.3.1 ja 2.3.2 esitettyjen DH- ja RSA-menetelmien lisäksi muita julkisen avaimen kryptomenetelmiä ovat mm. ElGamal ja DSA. Taher ElGamalin vuonna 1985 kehittämä ElGamal-menetelmä muistuttaa Diffie-Hellman -algoritmia ja se on kehitetty digitaaliseen allekirjoitukseen. Tästä huolimatta sitä voidaan käyttää myös salaukseen. ElGamal-menetelmää käytetään eniten symmetristen istuntoavainten salaamiseen. Menetelmää ei ole patentoitu ja sitä voidaan käyttää tällä hetkellä täysin vapaasti. ElGamal perustuu diskreetin logaritmin ongelmaan äärellisessä multiplikatiivisessa ryhmässä.

ElGamal-menetelmän varmuus on samaa luokkaa kuin RSA:n samanpituisilla avaimilla. Koska ElGamal edellyttää sanoman satunnaistamista, on se RSA:ta hitaampi. ElGamal -salaus tuottaa kaksi kertaa selväkielisanomaa suuremman sanoman.

DSA on USA:n hallinnon digitaalisen allekirjoituksen algoritmi. Tähän perustuu myös DSS-standardi (Digital Signature Standard). DSA käyttää periaatteita ElGamal-menetelmästä ja SHA-tiivistefunktiota (katso luku 2.2.1). DSA-algoritmia ei voi käyttää salaukseen, vaan sillä generoidaan yksinomaan digitaalisia allekirjoituksia.

Käytettäessä digitaalista allekirjoitusta liitetään se alkuperäiseen sanomaan ja siirretään joko vastaanottajalle tai tallennetaan muistiin tilanteesta riippuen. Allekirjoitus generoidaan käyttäen salaista avainta. Vastaanotetusta sanomasta tarkistetaan tiiviste, allekirjoitus sekä tarkistusluku ennen kuin viesti voidaan hyväksyä. Tarkistusluku lasketaan tiivisteen ja allekirjoituksen avulla. Kuvassa 1 on esitetty DSA:n toimintaperiaate.

Kuva 1: DSA:n toiminta.

2.4 Sertifikaatit ja julkisen avaimen infrastruktuuri

Julkisen avaimen sertifikaateilla taataan, ettei julkisen avaimen luovuttaja ole salakuuntelija. Tällä vältetään tilanteet, jossa osapuoli A yrittää saada osapuolen B julkisen avaimen haltuunsa, mutta saakin osapuolen B avaimen sijasta salakuuntelija C:n julkisen avaimen.

Sertifiointiin liittyy aina luotettava kolmas osapuoli (Trusted Third Party, TTP). Tässä tapauksessa TTP on sertifikaattori (Certification Authority, CA), joka voi olla viranomainen, jokin varmenneorganisaatio tai esimerkiksi yrityksen varmennuselin. TTP:n kautta kaksi toisilleen tuntematonta osapuolta voivat luottaa toisiinsa, koska luottavat molemmat yhteiseen kolmanteen osapuoleen. Julkisen avaimen sertifikaatissa tulee olla ainakin tunnistustiedot kohteesta, julkisen avaimen arvo, CA:n nimi ja CA:n digitaalinen allekirjoitus.

TTP-palvelut toteutetaan julkisen avaimen infrastruktuurin (Public Key Infrastructure, PKI) päälle. PKI on julkisen avaimen salaukseen, digitaaliseen allekirjoitukseen ja avainten hallintaan tarvittava järjestelmä. Esimerkiksi loogisesti turvattu yritysverkko, eli VPN (Virtual Private Network) käyttää PKI-sovelluksia. Käyttämällä digitaalisia allekirjoituksia PKI mahdollistaa mm. luotettavan tunnistuksen, tiedon eheyden ja tuen kiistämättömyydelle. Tärkein PKI-standardi on X.509, jossa määritellään tarvittavat sertifikaatit sekä niiden todentamismenettelyt.

PKI-järjestelmän tärkein ominaisuus on sen läpinäkyvyys (engl. transparent). Tämän lisäksi PKI-järjestelmän tulee huolehtia seuraavista asioista:

· julkisen avaimen sertifikaateista,

· sertifikaattien säilytyksestä,

· sertifikaattien kumoamisesta,

· avaimen varmuuskopioinnista ja palauttamisesta (engl. recovery),

· automaattisesta avainparien ja sertifikaattien päivityksestä sekä

· avainhistorian ylläpidosta.

PKI-järjestelmä voi sisältää tuen myös ristiinvarmennukselle ja digitaalisten allekirjoitusten kiistämättömyydelle. Lisäksi järjestelmän tulee sisältää työasemaohjelmisto.

PKI:n lisäksi on määritelty myös yksinkertaisempaa PKI-järjestelmä, SPKI (Simple PKI, ”spoogi”). SPKI-strategiassa SPKI-sertifikaatilla myönnetään julkisen avaimen valtuuksia tai käyttöoikeuksia tarvitsematta sitoa julkista avainta vastaavaan salaisen avaimen haltijana olevaan identiteettiin. SPKI-sertifikaatti voi esimerkiksi myöntää jollekin julkiselle avaimelle luvan autentikoida Internet-yhteyksiä käyttämällä Telnet-protokollaa erityisellä käyttäjätunnuksella nimettyyn palvelimeen määrättynä aikavälinä [Kerttula, s.383].

3 Tietoturvaprotokollat ja -standardit

Luvussa käsitellään yleisimpiä tietoturvastandardeja ja niiden ominaisuuksia sekä toimintaperiaatteita. Internet on TCP/IP-protokollia hyväksikäyttävien verkkojen globaali verkko. Tästä syystä keskitytään lähinnä TCP/IP-yhteyksien suojaamiseen kehitettyihin menetelmiin. Luku perustuu lähteisiin [Dierks], [Freier], [Kerttula] ja [Kohl] sekä SSH -standardeihin [Ylönen].

3.1 Tietoturva verkkotasolla

Verkkotuotteet jaetaan käytännössä nykyään kolmitasoisesti sovellusohjelmistoon, verkkoprotokolliin ja verkkolaiteohjelmiin. Tietoliikenteen OSI-viitemallin kerrokset sijoittuvat tähän kolmitasomalliin kuvan 2 osoittamalla tavalla. Itse kryptomekanismit sijoitetaan yleensä joillekin näistä tasoista tai näiden elementtien väliin.

Kuva 2: OSI-malli ja kolmitaso.

Tiedonsiirrolle voidaan asettaa erilaisia tavoitteita. Useimpien organisaatioiden pääasiallisin tavoite on salausratkaisujen edullisuus ja helppokäyttöisyys, sillä kalliit ja vaikeasti käytettävät ratkaisut ovat epärealistisia monelle. Usein kuitenkin korkeammat kustannukset hyväksytään turvallisuuden parantamiseksi. Luottamuksellisuus on tärkeää useimmille organisaatioille, mutta joillekin se on avainkysymys. Jopa yhden ainoan sanoman vuotaminen ulkopuolisen tietoon voi vahingoittaa vakavasti organisaation tavoitteita ja aiheuttaa vahinkoa, josta voi olla erittäin vaikeaa toipua [Kerttula, s. 208].

3.2 SSL (Secure Sockets Layer)

Internetin yleisin tietoturvaprotokolla on SSL. Se on yleiskäyttöinen ja sisältyy myös Netscapen ja Microsoftin selaimiin. Tuorein versio SSL:stä on 3.0. Alunperin SSL on Netscapen kehittämä salausmenetelmä, mutta siitä on kuitenkin tullut Internet-istuntojen defacto-menetelmä. SSL:n pohjalta kehitetään IETF:n toimesta myös TLS-protokollaa (Transport Layer Security), joka osaltaan kertoo SSL:n luotettavuudesta.

3.2.1 SSL:n ominaisuudet

SSL mahdollistaa kahden sovelluksen välisen turvallisen tiedonsiirron ja se on vapaasti käytettävissä. Se on sovelluksesta riippumaton ja mahdollistaa kanavan tietoturvan. SSL:n kolme perusominaisuutta ovat luotettava siirto, olion autenttisuus ja tiedon eheys. SSL toimii TCP/IP:n ja sovellusten välissä. Se on riippumaton sovelluksista ja siten myös sovelluksille näkymätön. Tästä johtuu myös se, että SSL ei ehkä ole tehokkaimmillaan WWW-selailussa. Lisäksi SSL-liikenteen on käytettävä omaa TCP/IP-kanavaa (engl. TCP-socket).

SSL:n tärkeimpiä ominaisuuksia on joustavan salaus-, tiivistys- ja autentikointimekanismin valinta. Taulukossa 1 on esitelty SSL-työkalupakin (engl. toolkit) versioiden 2.0 ja 3.0 tärkeimmät ominaisuudet. Salausmenetelmät on kuvattu lyhyesti luvussa 2.

Salauspakki	Vahvuus	SSL-versio	Kuvaus
DES-CBC3-MD5	Hyvin korkea	v2.0, v3.0	Triple-DES CBC-moodissa, MD5-tiiviste, 168 bitin istuntoavain.
DES-CBC3-SHA	Hyvin korkea	v2.0, v3.0	Triple-DES CBC-moodissa, SHA-tiiviste, 168 bitin istuntoavain.
RC4-MD5	Korkea	v2.0, v3.0	RC4, MD5-tiiviste, 128 bitin avain
RC4-SHA	Korkea	v3.0	RC4, SHA-tiiviste, 128 bitin avain
RC2-CBC-MD5	Korkea	v2.0, v3.0	RC2 CBC-moodissa, MD5-tiiviste, 128 bitin avain
DES-CBC-MD5	Keskitasoa	v2.0, v3.0	DES CBC-moodissa, MD5-tiiviste, 56 bitin avain
DES-CBC-SHA	Keskitasoa	v2.0, v3.0	DES CBC-moodissa, SHA-tiiviste, 56 bitin avain
EXP-DES-CBC-SHA	Matala	v3.0	DES CBC-moodissa, SHA-tiiviste, 40 bitin avain
EXP-RC4-MD5	Matala	v2.0, v3.0	Vientitasoinen RC4, MD5-tiiviste, 40 bitin avain
EXP-RC2-CBC-MD5	Matala	v2.0, v3.0	Vientitasoinen RC2, MD5-tiiviste, 40 bitin avain
NULL-MD5	-	v2.0, v3.0	Ei salausta, MD5-tiiviste, pelkkä autentikointi
NULL-SHA	-	v3.0	Ei salausta, SHA-tiiviste, pelkkä autentikointi

Taulukko 1: SSL-protokollan salausalgoritmit [Kerttula, taulukko 7.3].

3.2.2 SSL-istunnon muodostaminen

SSL-istunto muodostuu tiloista. Tilanvaihdoista huolehtii SSL Handshake -protokolla, jonka tehtävänä on yhteyden muodostus ja yhteyden aikana käytettävistä menetelmistä sopiminen. Muodostettaessa SSL -yhteyttä neuvotellaan alussa sopiva suojauspaketti (engl. cipher suite). Tavallisesti molemmat yhteyden osapuolet yrittävät ottaa käyttöön vahvimmat salausmenetelmät, jotka niillä molemmilla on. SSL-protokolla on 9-vaiheinen neuvottelu, jossa autentikoidaan molemmat osapuolet ja luodaan istuntoavain. Kuvan 3 kaaviossa on havainnollistettu SSL-yhteyttä.

Aluksi asiakassovellus avaa yhteyden palvelimen porttiin ja lähettää ClientHello-sanoman. Se sisältää asiakaspään suojausmahdollisuudet, sekä sen käyttämän SSL-version numeron, salauspakin ja datakompressiomenetelmän. Palvelin vastaa tähän viestiin ServerHello-sanomalla, jossa palautetaan palvelimen valitsema salauspakki ja datakompressiomenetelmä sekä senhetkisen istunnon tunnus. Mikäli palvelin ja asiakas eivät pääse yhteisymmärrykseen käytetyistä menetelmistä, lähetetään asiakkaalle virheilmoitus (handshake failure) ja katkaistaan yhteys.

Mikäli yhteisymmärrykseen päästään, lähettää palvelin sertifikaattinsa. Optiotoiminteena voidaan myös asiakkaalta pyytää sertifikaattia, jolloin asiakas lähettää palvelimelle sertifikaattinsa. Mikäli sertifikaattia ei ole, lähetetään no sertificate -sanoma. Tällöin yhteys voidaan jälleen purkaa palvelimen toimesta handshake failure -sanomalla.

Kun sertifikaatit on hyväksytty, lähettää asiakas ClientKeyExchange-sanoman. Tässä vaiheessa muodostetaan symmetrinen istuntoavain. Yksityiskohdat vaihtelevat valitun SSL-työkalupakin mukaan. Tavallisesti työasema generoi aluksi salaisen esiavaimen (engl. premaster key) turvallisella satunnaislukugeneraattorilla. Tätä avainta käytetään luotaessa lopullista, istuntoavaimena käytettävää varsinaista eli master-avainta. Koska symmetriset eri salausmenetelmät käyttävät eripituisia avaimia, ei istuntoavainta luoda suoraan.

Asiakassovellus kryptaa istuntoavaimen muodostamalla digitaalisen kirjekuoren käyttämällä palvelimen julkista RSA-avainta. Suljettu kuori lähetetään nyt palvelimelle.

Optiona työasema voi lähettää nyt CertificateVerify-sanoman sisältäen esiavaimen, jota on manipuloitu eri tavoilla yhteyttä kuuntelevien peukalointien estämiseksi. Näin syntynyt salainen tieto allekirjoitetaan asiakkaan salaisella RSA-avaimella ja lähetetään palvelimelle, jonka voimassaolon palvelin tarkastaa asiakkaan sertifikaatin sisältämien tietojen perusteella. Koska asiakas lähettää salaisen esiavaimen kryptattuna palvelimen julkisella RSA-avaimella, sen voi purkaa vain sertifikaatin laillinen omistaja. Jos edellisessä käytetään asiakkaan autentikointia, pitää asiakkaan autentikoida itsensä palvelimelle todistamalla, että se tuntee aidon salaisen RSA-avaimen.

Asiakas ja palvelin lähettävät molemmat ChangeCipherSpec-sanoman, jossa vahvistetaan molempien olevan valmiina aloittamaan suojatun liikenteen käyttämällä sovittua menetelmää ja istuntoavainta. Molemmat lähettävät vielä finished-sanomat, jotka muodostuvat koko yhteyden aikana kertyneestä MD5- ja SHA-tiivisteistä. Näin molemmat osapuolet voivat todentaa, että niiden vastaanottamat sanomat olivat kunnossa, eikä niitä ole muutettu matkalla. Tässä vaiheessa molemmat vaihtavat toimintansa kryptomoodiin käyttämällä istuntoavainta salatakseen liikenteen molempiin suuntiin.

Kuva 3: Sekvenssikaavio SSL-yhteydestä.

SSL:n versiossa 3.0 palvelin voi sertifikaatin lähettämisen sijaan lähettää ServerKeyExchange-sanoman, jota käytetään istuntoavaimen sopimiseksi ilman palvelimen sertifikaattia. Näin voi käydä kolmessa eri tapauksessa: palvelin käyttää anonyymia Diffie-Hellman -avaimenvaihtoprotokollaa, palvelin käyttää salaamiseen Fortezza-älykorttia tai palvelimella on vain salainen allekirjoitusavain.

Kaikki SSL-liikenne on salattua, kuten esimerkiksi pyydetyn dokumentin URL ja sisältö, täyttökaavakkeiden sisällöt, keksit (engl. cookies) sekä HTTP-otsikoiden sisällöt. SSL-protokolla on yhdeksän vaiheinen neuvottelu, jossa autentikoidaan molemmat osapuolet ja luodaan istuntoavain.

3.2.3 SSL:n arkkitehtuuri

SSL on monikerrosprotokolla, joka jakaa sovelluksen datan sopivan mittaisiin lohkoihin, tiivistää datan tarvittaessa, hyväksyy MAC-koodin (Message Authentication Code), kryptaa datan ja lähettää lopputuloksen eteenpäin. MAC on kryptografinen sanoman tai viestin tarkistussumma ja sitä käytetään yleisesti eheyden tarkistamiseen.

Tietuekerros (SSL Record Layer) on SSL-protokollan kerros, joka vastaanottaa sovelluskerrokselta mielivaltaisen pituisia sanomia. Nämä sanomat pilkotaan 2¹⁴ tavun kokoisiin, tai pienempiin paketteihin. Kaikki tietueet pakataan istunnon alussa neuvotellun tiivistysalgoritmin mukaisesti. Lisäksi kaikki tietueet suojataan niin ikään yhteyden alussa sovitulla kryptausmenetelmällä ja MAC-algoritmilla.

Tietuekerroksen lisäksi SSL:ssä on määritelty Alert-protokolla, CCSP (Change cipher spec protocol), Handshake-protokolla sekä Application-, eli sovellusprotokolla. Handshake-protokollalla muodostetaan yhteys ja neuvotellaan yhteyden parametreistä ja käytettävistä menetelmistä.

Alert-protokollaa käytetään virhetilanteissa virheiden ilmaisemiseen. Virhetilanteet syntyvät havaittaessa protokollan vastaista toimintaa tai siinä tapauksessa jos parametrien neuvottelussa osapuolet eivät tue samoja algoritmeja. Alert-protokollalla voidaan luokitella virhetilanteiden vakavuudet ja sitä käytetään myös salatun yhteyden sulkemiseen.

CCSP-viesti lähetetään molempien osapuolien toimesta, kun halutaan ilmoittaa seuraavien pakettien olevan salattuja neuvoteltujen salausmenetelmien mukaisesti. Sovellusprotokollaa käytetään varsinaisen salattavan tiedon lähettämiseen tietuekerroksen päällä. Tätä voidaan käyttää vasta kun Handshake-protokolla on suoritettu hyväksytysti loppuun asti.

3.3 Secure HTTP ja PCT (Private Communication Technology)

S-HTTP on CommerceNetin julkaisema kilpailija SSL:lle. S-HTTP mahdollistaa yleisen tietoturvaprotokollan transaktiosovelluksiin, joita ovat mm. luotettavat tapahtuman käsittelyt, autentikoinnin, sanomien eheyden ja alkuperän kiistämättömyyden. S-HTTP perustuu julkisen avaimen RSA-menetelmään ja tavalliseen salaisen avaimen käyttöön, sekä Kerberos-pohjaiseen turvajärjestelmään. Kerberos v5 -standardi on esitetty luvussa 3.7. S-HTTP tukee turvallista sanomanvälitystä päästä-päähän yhteyksillä.

S-HTTP toteuttaa tietoturvaa hieman eri lähtökohdasta SSL:ään nähden. Se perustuu täysin olemassa olevaan HTTP-protokollaan. S-HTTP -protokollat on integroitu HTTP-protokollaan ja tietoturvasta neuvotellaan sivupohjaisesti otsikoiden mukana. S-HTTP ei ole saavuttanut merkittävää kaupallista asemaa.

PCT on Microsoftin kehittämä kilpailija SSL:lle. Myös PCT:n tavoitteena on estää asiakas/palvelin -sovellusten salakuuntelua siten, että palvelin tunnistetaan, eli autentikoidaan aina ja tarvittaessa myös käyttäjä. Kuten SSL, myös PCT on sovellusriippumaton ja se on näkymätön sen päällä oleville sovelluksille. PCT-protokollan formaatti on yhteensopiva SSL:n kanssa.

3.4 SSH2-protokolla

SSH –protokollaa (Secure Shell) käytetään salattujen etäyhteyksien lisäksi turvallisten palvelujen toteuttamiseen verkossa, jossa turvallisuutta ei voida taata. Versio SSH1 on tarkoitettu pääteyhteyksien login-vaiheiden suojaamiseen. SSH2 pystyy sen sijaan suojaamaan yhteydet kaikissa istunnon vaiheissa ja siten sitä voidaan käyttää myös hajautetuissa sovelluksissa tietoturvaratkaisuna. Tutkielmassa tarkoitetaan SSH:lla nimenomaan SSH2-protokollaa.

Tavallisesti SSH-protokollaa käytetään TCP/IP-yhteyksillä, mutta sitä voidaan käyttää myös muiden proxy-yhteyksien läpi datan siirtämiseksi palvelimelle (tai palvelimelta). SSH-protokollalle on varattu porttinumero 22.

3.4.1 SSH2:n arkkitehtuuri

SSH2 muodostuu kolmesta pääkomponentista: siirtoprotokollasta (Transport Layer Protocol), autentikointiprotokollasta (User Authentication Protocol) ja yhteysprotokollasta (Connection Protocol). Siirtoprotokolla mahdollistaa palvelimen autentikoinnin sekä siirron luottamuksellisuuden ja eheyden. Siirtoyhteys voidaan tarvittaessa tiivistää, eli kompressoida. Yleensä siirtoprotokollaa käytetään TCP/IP:n päällä, mutta sitä voidaan käyttää myös muun luotettavan kuljetusprotokollan päällä.

Autentikointiprotokolla toimii siirtoprotokollan päällä ja se autentikoi työaseman palvelimelle. Yhteysprotokolla multipleksaa suojatun tunnelin usealle loogiselle kanavalle ja se toimii autentikointiprotokollan päällä. Lisäksi se tarjoaa yhteyksien edelleenohjausta.

3.4.2 Yhteyden muodostus

Kullakin palvelimella tulisi olla oma avain (engl. host key), jolla asiakas varmistuu palvelimen oikeellisuudesta avainten sopimisen aikana. Tämä toteutetaan julkisen avaimen menetelmällä. Palvelimella voi olla myös useampi host-avain, jotka voivat olla eri algoritmeja varten.

SSH:ssa voidaan neuvotella käytettävistä salaus-, tiedon eheys-, avainten vaihto-, tiivistys- ja julkisen avaimen menetelmistä sekä avainten formaatista. Menetelmät voivat olla yhteyden osapuolilla erilaiset, kunhan toinen osapuoli on toisen käyttämistä menetelmistä selvillä ja kykenee toteuttamaan yhteyden niiden mukaisesti.

Avainten vaihto aloitetaan lähettämällä lista tuetuista algoritmeista molemmin puolin. Yhteyden osapuolet voivat yrittää arvata toisen käyttämää algoritmia lähettämällä tämän arvauksen mukaan salatun sanoman toiselle osapuolelle. Vastaanottaja hyväksyy sanoman ainoastaan, jos arvaus oli oikea. Muussa tapauksessa käytettävästä menetelmästä on neuvoteltava. Avainten vaihdon jälkeen asiakas pyytää joko ssh-useraut-h tai ssh-connection-palvelua. Käyttäjä autentikoi itsensä ssh-userauth-protokollalla ja ssh-connection suorittaa yhteyden multipleksauksen.

Autentikointitapahtumaa ohjaa palvelin kertomalla asiakkaalle autentikointimetodeista, joita voidaan käyttää siirron jatkamiseksi. Asiakkaalla on mahdollisuus yrittää käyttää näitä autentikointimetodeja missä tahansa järjestyksessä. Asiakas lähettää palvelimelle autentikointipyynnön, jonka palvelin joko hyväksyy tai hylkää. Pyyntö sisältää autentikointimetodin ja autentikointiin tarvittavan informaation lisäksi tiedon palvelusta, jota onnistuneen autentikoinnin jälkeen pyydetään.

3.4.3 Salausalgoritmit SSH2:ssa

SSH2:ssa käytetään salaukseen, tiivistämiseen ja julkisen avaimen menetelminä ainoastaan tunnettuja ja hyvin muodostettuja algoritmeja. Ts. SSH:ssa sallittujen algoritmien oletetaan olevan turvallisia kryptograafisia hyökkäyksiä vastaan vielä vuosikymmeniä. Lisäksi SSH:ssa on painotettu joustavaa arkkitehtuuria menetelmän laajentamisen kannalta.

SSH-standardi määrittelee pakolliseksi kryptausmenetelmäksi ainoastaan 3DES-EDE:n CBC-moodissa (katso luku 2.1.1). Suositeltavina ja valintaisina menetelminä SSH-standardi määrittelee toteutuksille seuraavat kryptausmenetelmät:

· Blowfish-CBC (katso luku 2.1.9),

· Twofish-CBC 256-, 192- ja 128-bittisillä avaimilla,

· AES-CBC 256-, 192- ja 128-bittisillä avaimilla,

· Serpent-CBC 256-, 192- ja 128-bittisillä avaimilla,

· ARCFOUR sekä

· IDEA-CBC.

Nämä ovat ARCFOURia lukuunottamatta lohkosalaajia. ARCFOUR -nimitystä (Alleged RC4) käytetään toteutuksesta joka on ekvivalentti RC4:n kanssa (katso 2.1.3).

Tiivistefunktioista pakolliseksi on määrätty SHA (katso luku 2.2). Suositeltavia tai valinnaisia tiivistealgoritmeja ovat lisäksi MD5, MD5-96 sekä SHA-96. MD5-96 ja SHA-96 käyttävät vain 96 ensimmästä bittiä koko tiivisteestä (katso luku 2.2).

Suositellut ja valinnaiset julkisen avaimen algoritmit ovat pakollisen SSH-DSS:n lisäksi Diffie-Hellman (katso luku 2.3), PKI:hin perustuvat X.509 -sertifikaatit, SPKI-sertifikaatit (Simple PKI) ja OpenPGP-sertifikaatit (katso luku 2.4).

3.5 TLS ( Transparent Layer Security)

TLS on IETF:n standardi, joka on kehitetty SSL:n pohjalta (katso luku 3.1). TLS:n kaksi ensisijaista turvallisuustavoitetta ovat tiedonsiirron yksityisyys ja tiedon eheys. Lisäksi TLS:llä voidaan todentaa olion autenttisuus, joka ei tosin ole pakollinen osa protokollaa. Lähtökohtana TLS:n standardoinnissa on ollut yhteensopivuus, laajennettavuus sekä tehokkuus. TSL:stä löytyy sekä kaupallisia, että ilmaisia toteutuksia.

SSL:n tapaan TSL sijoittuu protokollapinossa luotettavan kuljetuskerroksen (katso kuva 2 sivulla 7) päälle, eikä se ole riippuvainen ylemmästä kerroksesta. Itse TSL jakautuu kahteen kerrokseen. Alemman kerroksen, eli tietuekerroksen (TLS Record Protocol, Record Layer) tehtävänä on huolehtia datan pakkauksesta, salauksesta ja sanoman pilkkomisesta sopivan kokoisiin osiin. Tällä kerroksella huolehditaan siirron yksityisyydestä kryptaamalla data. Kryptaus voidaan suoritta esimerkiksi DES- tai RC4-menetelmillä (katso luvut 2.1.2 ja 2.1.3). Myös yhteyden luotettavuudesta ja tiedon eheydestä huolehditaan tällä kerroksella käyttäen tiivistefunktioita (esim. SHA tai MD5; katso luku 2.2). Tietuekerroksella kapseloidaan ylemmän tason protokollia. Vastaanotettaessa dataa tietuekerros vastaavasti kokoaa sanoman ja purkaa salauksen.

Ylemmän kerroksen (TLS Handshake Protocol) muodostavat CCSP (Change Cipher Spec Protocol), Alert Protocol, Handshake Protocol ja Application Protocol. Ylemmällä kerroksella huolehditaan autentikoinnista. Tämä voidaan toteuttaa salaisen tai julkisen avaimen menetelmillä (esim. RSA, Diffie-Hellman ja DSS; katso luvut 2.3.1, 2.3.2, 2.3.3).

Handshake-protokollaa käytetään TLS-yhteyden avaamiseen. Yhteyttä muodostettaessa neuvotellaan SSL:n tapaan käytettävät salaus- ja tiivistysalgoritmit sekä generoidaan avaimet ja suoritetaan mahdollinen autentikointi. Algoritmi on hyvin samankaltainen kuin SSL:ssä, joten sitä ei käydä tässä läpi. Myös ylemmän kerroksen protokollat vastaavat SSL:n vastaavia protokollia.

3.6 HTTPS

HTTPS:n konsepti on yksinkertainen, sillä siinä käytetään HTTP-protokollaa TCP:n sijasta TLS:n tai SSL:n päällä. Kaikki HTTP-data lähetetään TLS:n tai SSL:n kannalta normaalina sovellusdatana. HTTPS-yhteyksissä oletusporttina on 443.

3.7 Kerberos v5

Kerberos on luotettavan kolmannen osapuolen palveluihin perustuva avaimenvaihto- ja autentikointiprotokolla. Kerberos perustuu luotettavan kolmannen osapuolen ideologiaan, jossa kaksi toisilleen tuntematonta osapuolta muodostavat luotettavan yhteyden kolmannen osapuolen kautta, johon molemmat luottavat.

3.7.1 Identiteettien autentikointi

Kerberoksessa käyttäjistä ja yleensä palveluita käyttävistä identiteeteistä käytetään nimitystä principals, joiden tunnistamiseen Kerberos tarjoaa menetelmät. Autentikointiprosessissa asiakas lähettää pyynnön autentikointipalvelimelle (Authentication Serve,r AS), jolla pyydetään ns. kredentiaaleja (engl. credentials). Kredentiaalit ovat eräänlaisia valtakirjoja. Pyynnössä viedään AS:lle pyydettävän palvelun tunniste, asiakkaan identifiointi-informaatio sekä kellonaika. Ennen vastauksen lähettämistä AS salaa vastauksen asiakkaan salaisella avaimella.

AS edustaa luotettavaa kolmatta osapuolta, joka ylläpitää tietoa identiteeteistä ja niiden salaisista avaimista. AS:ltä saadaan vasteena varsinaiselle palvelimelle määrittelevät käyttäjän oikeudet, eli lipun (engl. ticket) ja väliaikaisen salausavaimen, jota kutsutaan myös istuntoavaimeksi (engl. session key). Lisäksi vaste sisältää aikaleiman, jolla varmistetaan että vastaus ei ole monistettu aiemmin lähetetystä vastauksesta.

Lippu koostuu mm. asiakkaan identiteettitiedoista, istuntoavaimesta ja aikaleimasta. Lippu on salattu palvelimen salaisella avaimella. Saatuaan kredentiaalit asiakas lähettää lipun palvelimelle. Istuntoavaimella autentikoidaan käyttäjä ja tarvittaessa myös palvelin. Sitä voidaan käyttää myös tiedon salauksessa tai uuden avaimen generoinnissa, jota sitten käytetään varsinaisen datan salaamiseen. Istuntoavainta ei välitetä koskaan verkon yli selväkielisenä, jolla varmistutaan asiakkaan autenttisuudesta ja tiedon oikeellisuudesta lipun tietojen avulla.

Lippu sisältää myös ns. autentikoijakentän (engl. authenticator), jolla asiakas vahvistaa palvelimelle tuntevansa istuntoavaimen. Autentikoija sisältää mm. kellon ajan, asiakkaan tunnistusinformaation ja asiakkaan verkko-osoitteen. Autentikoija salataan istuntoavaimella. Saatuaan lipun palvelin purkaa autentikoijan lipussa olevalla istuntoavaimella ja tarkastaa sen. Kun varsinainen palvelin on hyväksynyt lipun, voidaan aloittaa kommunikointi tai neuvotella uudesta avaimesta.

Kryptaus perustuu Kerberoksessa DES-algoritmiin (katso luku 2.1.1), mutta muitakin algoritmeja voidaan käyttää. Kuvassa 4 on esitetty Kerberos-menetelmän autentikointi sekvenssikaaviona.

Kuva 4: Kerberos-autentikointi.

3.7.2 Kerberos-järjestelmän vaatimukset

Kerberos-järjestelmän toteutus koostuu siis yhdestä tai useammasta autentikointipalvelimesta, jossa on tietokanta käyttäjistä ja niiden salaisista avaimista. Autentikointipalvelimeen kohdistuu siten suuria tietoturvavaatimuksia.

Kerberos asettaa muutamia oletuksia toimintaympäristölleen. Protokolla mahdollistaa joissain kohdissa salakuuntelijan häiritsemisen autentikoinnissa siten, että sovellukselta estetään osallistuminen kaikkiin autentikoinnin vaiheisiin. Käyttäjien (engl. principal) on pidettävä avaimensa salassa. Lisäksi hyökkääjän on mahdollista arvata käyttäjän valitsema salasana. Kaikki verkon host-koneiden kellot on oltava jokseenkin synkronoitu. Jos synkronointiin käytetään protokollaa, on sen oltava turvallinen. Myöskään käyttäjien tunnisteita (engl. principal id) ei suositella kierrätettävän lyhyellä aikavälillä.

4 Hajautusmenetelmät ja niiden tietoturvaratkaisut

Hajautetuissa järjestelmissä pyritään järjestelmän loogiset kokonaisuudet hajauttamaan eri prosesseiksi. Toiminnallisuuden hajauttamiseen liittyy usein prosessien hajauttaminen verkon eri pisteisiin. Tällöin prosessit kutsuvat toisiaan verkon yli jollain yhteisellä protokollalla.

Hajautettujen järjestelmien etuja ovat perinteisiin järjestelmiin nähden helpompi ylläpidettävyys ja hallittavuus. Nämä edut saavutetaan kuitenkin vain huolellisella arkkitehtuurisuunnittelulla, johon kuuluu oleellisesti myös monikerrosarkkitehtuuri. Hyvin suunnitellun järjestelmän päivittämisen ei tule vaikuttaa kaikkiin loogisiin kokonaisuuksiin, vaan se on pyrittävä tekemään mahdollisimman näkymättömäksi muille kokonaisuuksille.

Hajautetuilla järjestelmillä voidaan parantaa myös tietoturvaa sijoittamalla arkaluontoinen tieto (SQL-lauseet, tiedostojen nimet, laskukaavat ja salasanat ) suljettuun verkkoympäristöön, eikä esimerkiksi käyttöliittymän toteutukseen tai WWW-palvelimelle.

Internetin kehittymisen ja yleistymisen myötä sovellusten hajautus on tullut helpommaksi ja tehokkaammaksi. Tämän päivän monet palvelut kannattaa toteuttaa (ja on myös toteutettu) hajautetusti, jolloin esimerkiksi monikäyttäjäympäristö on helpompi toteuttaa ja hallita. Tässä luvussa käsitellään yleisimpiä hajautusmenetelmiä ja menetelmiä, joihin nykyiset hajautusmenetelmät perustuvat. Luvun oleellisimpia lähteitä ovat [Alireza], [Horstman], [Sun], [Network Working Group], [Orfali] ja [Weiss].

4.1 Soketit

Sokettiohjelmoinnilla voisi periaatteessa toteuttaa hajautetun järjestelmän, mutta se olisi kohtuuttoman työlästä verrattuna olemassa oleviin hajautusmenetelmiin. Tässä luvussa esitellään kuitenkin hieman sokettiohjelmointia. Se on TCP/IP-yhteyksien yli tapahtuvan, prosessien välisen kommunikoinnin perusmenetelmiä, joihin perustuvat myös useimmat hajautusmenetelmät (esim. CORBA, luku 4.3).

Sokettiohjelmointi perustuu soketteihin (engl. socket). Internetsoketti määrittelee IP-osoitteen ja porttinumeron. Soketilla on kaksi tietovirtaa: luku- (engl. input stream) ja kirjoitusvirta (engl. output stream). Prosessi kommunikoi verkon yli toisen prosessin kanssa kirjoittamalla tietovirtaan, josta toinen prosessi lukee datan. Javassa sokettivirtaan kirjoittaminen ei poikkea mitenkään muuhun tietovirtaan kirjoittamisesta yhteyden muodostuksen jälkeen.

Sokettiparilla voidaan määrätä täysin kahden pisteen välinen kommunikointi. Kommunikointi voi tapahtua TCP:n lisäksi myös yhteydettömän UDP:n päällä, jolloin puhutaan datagrammi-soketeista. Kommunikoinnin aloittaminen edellyttää, että toinen prosessi kuuntelee porttia, johon toinen yrittää ottaa yhteyden. Tilanne on siis aivan kuin puhelinliikenteessä, jossa puhelun vastaanottaja odottaa puhelimen soimista. Vastaavasti, kun soittajan on tunnettava puhelinnumero, on soketti-ohjelmoinnissa tunnettava kuuntelevan prosessin IP-osoite ja porttinumero

Itse yhteyden muodostuksessa asiakas ottaa yhteyden palvelimeen. Palvelin avaa sokettiyhteyden hyväksymällä yhteydenmuodostuspyynnön. Tämän jälkeen molemmat voivat kirjoittaa ja lukea dataa tietovirrasta. Käytännössä tietovirta on siis pysyvä yhteys kahden kommunikaatiopisteen välillä. Asiakkaan ja palvelimen välillä on kaksi tietovirtaa jota toista käytetään kirjoittamiseen ja toista lukemiseen. Palvelin lukee siis tietovirtaa, johon asiakas kirjoittaa ja päinvastoin.

Javassa voidaan tietovirraksi alustaa erilaisia pidemmälle kehitettyjä tietovirtoja, joissa voidaan esimerkiksi siirtää olioita (ObjectInputStream /ObjectOutputStream). Näin pystytään esimerkiksi välittämään komentoja asiakkaalta palvelimelle ns. komento-olioiden (engl. Command Object) mukana. Komento-olio voisi yksinkertaisimmillaan sisältää yhden kokonaislukuarvon vastaten jotain tiettyä komentoa, joka on määrätty asiakkaan ja palvelimen välillä käytettävässä rajapinnassa. Vastaavasti komentojen suorituksen jälkeen voidaan palauttaa jokin suoritusta kuvaava palautusarvo olion attribuutissa.

Sokettiohjelmoinnilla on helppo toteuttaa yksinkertaiset palvelut, joissa ei parametrien välitystä juuri tarvita. Jos palvelupyyntöön liittyy kuitenkin useita parametrejä ja kutsuja on lukuisia, tulee sokettiohjelmoinnista monimutkaista ja työlästä. Sokettiohjelmointia voisi verrata assembler-koodaukseen kun tarjolla olisi korkeamman tason ohjelmointikieliä.

4.1.1 JSSE (Java Secure Socket Extension)

Soketti-yhteydet voidaan luonnollisesti suojata SSL:llä tai TLS:llä (katso luvut 3.1 ja 3.4). Javan JSSE sisältää Java-toteutukset SSL:stä ja TLS:stä. JSSE mahdollistaa siis datan kryptauksen, autentikoinnin ja tiedon eheyden varmistamisen.

JSSE:n avulla voidaan toteuttaa turvallinen tiedonsiirto asiakkaan ja palvelimen välillä, jotka voivat käyttää sovellustason protokollana esimerkiksi HTTP:tä, Telnetiä tai FTP:tä. JSSE:tä käytetään TCP/IP-yhteyksillä. JSSE sisältää siis HTTPS-tuen. JSSE oli aiemmin laajennus Java 2 SDK:n (Software Development Kit) versioissa 1.2 ja 1.3, mutta versioon 1.4 se on integroitu. J2SDK 1.4 on saatavana ilmaiseksi mm. Sun Microsystemsin WWW-sivuilta (http://java.sun.com).

JSSE tarjoaa APIn (Application Programming Interface), eli sovellusohjelmointirajapinnan. JSSE API täydentää J2SDK:n version 1.4 pakettien (engl. package) java.security ja java.net turvallisuusominaisuuksia. J2SDK:n JSSE tukee SSL:n versiota 3.0 ja TLS:n versiota 1.0.

JSSE Standard API kattaa suojatut soketit (engl. Secure Sockets), palvelinsoketit, sokettitehtaat (engl. Socket Factories), rajapinnat avainten käsittelyyn ja tehtaat niiden luontiin, luokat turvalliseen HTTP-kommunikaatioon sekä julkisen avaimen käyttöön tarkoitetun APIn. JSSE on suunniteltu siten, että siihen voi liittää toteutuksia esimerkiksi PKI:sta näkymättömästi. Liittämiseen on kuitenkin olemassa lukuisia rajoituksia.

Avainten muodostus Sun Microsystemsin JSSE-toteutuksessa, SunJSSE:ssä, on toteutettu RSA-algoritmilla (katso luku 2.3.2) ja allekirjoitukset RSA:lla yhdessä joko SHA- tai MD2/MD5-tiivistysalgoritmien (katso luku 2.2) kanssa. JSSE:ssä toteutetut salausmenetelmät on esitetty taulukossa 2.

Menetelmä	Käyttö	Avaimen pituus (bittiä)
RSA	Julkisen avaimen menetelmänä autentikoinnissa ja avainten vaihdossa.	2048 autentikoinnissa ja 2048 tai 512 avainten vaihdossa.
RC4	Sanomien kryptaus	128 sekä 128, josta 40 käytössä.
DES	Sanomien kryptaus	64, josta 56 käytössä sekä 64, josta 40 käytössä.
3-DES	Sanomien kryptaus	192, josta 112 käytössä.
Diffie-Hellman	Avainten vaihto.	1024 ja 512.
DSA	Autentikointi.	2048

Taulukko 2: Salausmenetelmät JSSE:ssä.

JCE (Java Cryptography Extension) on kirjasto, joka sisältää toteutuksia useista kryptausalgoritmeista. JSSE sisältää samoja toteutuksia kuin JCE, mutta toisin kuin JCE:ssä JSSE:ssä ne on liitetty suoraan soketteihin. Tarvittaessa ohjelmoija voi käyttää JCE:tä tiedon salaamiseen, mutta se on työläämpää ja epäkäytännöllisempää kuin JSSE:n käyttö, joten JCE:tä ei käsitellä tutkielmassa tätä tarkemmin.

4.1.2 GSS-API (Generic Security Services Application Programming Interface)

GSS-API on rajapinta, joka tarjoaa turvallisuusratkaisuja sovellusohjelmoijille. GSS-APIn kautta voidaan käyttää salaisen ja julkisen avaimen menetelmiin perustuvia tietoturvamenetelmiä ja se pyrkii tarjoamaan näiden palveluita ohjelmointikielestä riippumatta. GSS-APIsta on myös Java-toteutus. On kuitenkin syytä huomioida, että kyseessä on vain rajapinta, joka vaatii taustalle myös todellisen kyseistä rajapintaa tukevan tietoturvamenetelmän toteutuksen.

Kerberos-menetelmän tapaan GSS-APIssa puhutaan valtakirjoista ja osapuolten välinen kommunikointi on token-pohjaista. Tavallisesti GSS-APIa kutsutaan jonkin protokollan toimesta haluttaessa käyttää tietoturvapalveluita siirrettävälle datalle. GSS-APIn kutsuja hyväksyy kutsun jälkeen GSS-API -toteutukselta saamansa tokenin ja lähettää sen vastaanottajalle, joka siirtää tokenin omalle GSS-API -toteutukselle. Tämä palauttaa alkuperäisen viestin vastaanottajalle.

Token on eräänlainen dataelementti. Tokenit jaetaan kahteen luokkaan. Context-level -tokeneilla ylläpidetään osapuolten välistä turvallista yhteyttä. Tämä yhteys perustuu edellä mainittuihin valtakirjoihin. Per-message -tokeneilla tarjotaan turvallisuuspalveluita sanomille. Vastaanotettaessa tokeneita GSS-APIn kutsujan on huolehdittava erityyppisten tokeneiden tunnistamisesta ja välittämisestä sopiville GSS-API -rutiineille.

GSS-API:n avulla voidaan järjestelmään liittää Kerberos-menetelmä. GSS-API ja JSSE tarjoavat sovellusohjelmoijalle samankaltaiset turvallisuusominaisuudet, eli asiakkaan ja palvelimen autentikoinnin, sekä datan kryptauksen ja eheyden. JSSE:llä ja GSS-APIlla on kuitenkin seuraavat erot:

· JSSE ei tue Kerberosta toisin kuin GSS-API.

· JSSE perustuu täysin soketteihin ja TCP/IP-teknologiaan, kun GSS-API on ns. token-pohjainen, jossa luotetaan sovelluksen huolehtivan yhteydestä. Tämä mahdollistaa erilaisten kuljetusprotokollien käytön.

· GSS-APIssa voidaan valita kaikki, tai vain jotkut sanomat kryptattaviksi, JSSE:ssä kryptataan aina kaikki sanomat.

· GSS-API ei sovellu HTTPS:n kanssa yhtä hyvin kuin JSSE, koska GSS-API ei perustu TLS:ään.

· GSS-API sopii Kerberos tuen vuoksi taas paremmin esimerkiksi LDAP-ratkaisuihin.

4.2 RMI (Remote Method Invocation)

RMI on Sun Microsystemsin kehittämä Java-pohjainen hajautusmenetelmä. RMI peittää sokettitason ja tietovirrat sovellusohjelmoijalta, jolloin ohjelmointi vastaa kutakuinkin lokaalisti ajettavan sovelluksen tekemistä. RMI siis mahdollistaa olioiden hajauttamisen siten, että olion ilmentymälle voidaan suorittaa kutsuja verkon yli.

RMI tukee perinteisiä asiakas-palvelin- ja peer-to-peer -arkkitehtuureita. Lisäksi se laajentaa niitä agentti-pohjaisilla menetelmillä, joilla voidaan siirtää olioiden sisältämän datan (attribuuttien arvojen) lisäksi niiden käyttäytyminen (metodit) kommunikoinnin osapuolten välillä. RMI on siis vahvasti oliopohjainen menetelmä, jossa metodikutsujen parametrit ja palautusarvot voivat olla olioiden ilmentymiä.

Sovellus voi kutsua RMI:n avulla etäolion metodia saatuaan referenssin tähän. Referenssi voidaan saada rekisteristä, jonne etäolioita rekisteröidään tai etäkutsun palautusarvona tai argumenttina. RMI-järjestelmä voidaan toteuttaa ainoastaan Java-kielellä, joka on varsin suuri rajoitus. RMI sisältää myös sisäänrakennetun roskienkeruumekanismin, joka poistaa tarpeettomat palvelinilmentymät. Nykyisin RMI:tä voidaan käyttää CORBAn määrittelemän IIOP:n (Internet Inter-ORB Protocol) avulla, jolloin RMI-toteutukset voidaan liittää CORBAlla toteutettuun järjestelmään. Tämän vuoksi RMI:n katsotaankin vähitellen sulautuvan CORBAan.

Olioiden välittäminen metodien parametreinä ja palautusarvoina edellyttää sarjallistamista (engl. serialization). Sarjallistaminen on tekniikka, jolla olioita voidaan muuttaa tietovirraksi ja tietovirrasta takaisin vastaavaksi ilmentymäksi. Sarjallistetut oliot toteuttavat Javan Serializable-rajapinnan. Olioiden välittäminen edellyttää siis, että olio voidaan sarjallistaa. Java 2 SDK:n luokista lähes kaikki voidaan sarjallistaa.

4.2.1 RMI-sovelluksen arkkitehtuuri

RMI-sovelluksen luomiseksi joutuu ohjelmoija kirjoittamaan asiakkaan ja palvelimen välisen rajapinnan sekä asiakkaan ja palvelimen toteutuksen. Palvelin koostuu ns. servantista ja itse palvelimesta. Servant-luokka toteuttaa rajapinnan, joten kullekin rajapinnalle on toteutettava yksi Servant-olio. Näiden luokkien lisäksi generoidaan rajapinnasta vielä ns. tynkä (engl. stub) ja runko (engl. skeleton), jotka toimivat asiakas- ja palvelinpäässä rajapinnan ja toteutusten välissä. Kuvassa 5 on esitetty yksinkertaisen RMI-sovelluksen arkkitehtuuri.

Kuva 5: RMI-arkkitehtuuri.

RMI sisältää myös joitain palveluja, jotka helpottavat etäolioiden käyttöä. RMI:n nimipalvelun (RMI Naming Service) avulla voidaan objekteja hakea URL-tyyppisillä merkkijonoilla. RMI mahdollistaa myös koodin lataamisen palvelimelta, joka tosin on suuri riski tietoturvan kannalta.

4.2.2 RMI:n tietoturva

RMI tarjoaa RMISecurityManager-luokan, joka on hyvin saman tyyppinen applettien käyttämän AppletSecurityManager-luokan kanssa. RMISecurityManager on yksinkertainen turvallisuusluokka, joka vastaa etäladatun koodin suorittamista operaatioista. Se ei siis salaa tietoa millään tavalla.

Salaukseen voidaan RMI:ssä käyttää luvussa 4.1.1 esitettyä JSSE:tä, jonka dokumentaatiosta löytyy myös esimerkkejä RMI-toteutuksista. Kaupallisista tuotteista mainittakoon SSLava (katso luku 4.6). Se on Phaosin monikäyttöinen tuote, jolla on suojattu tiedonsiirtoa myös CORBA-sovelluksissa. RMI-liikennettä voidaan salata myös käyttämällä SSH-tunnelointia, joka tosin ei ole kovin näppärä tapa toteuttaa tietoturvaa.

4.3 CORBA (Common Object Request Broker Architecture)

CORBA on kunnianhimoisimpia ja suurimpia väliohjelmistoprojekteja (engl. middleware) hajautettujen järjestelmien historiassa. CORBAn kehittämisestä vastaa OMG (Object Management Group), johon kuuluu yli 800 informaatioteknologia-alan yritystä. Huomattavana poikkeuksena tästä joukosta on Microsoft, joka on keskittynyt oman DCOM-menetelmänsä (luku 4.5) kehittämiseen.

CORBA on kieliriippumaton menetelmä, jossa voidaan toteuttaa esimerkiksi Java-asiakkaan ja C++ -palvelimen välinen kommunikointi. CORBA on laajalle levinnyt hajautusmenetelmä, jota käytetään nykyään myös langattomissa sovelluksissa.

4.3.1 ORB (Object Request Broker)

CORBA-menetelmä perustuu ORBiin, joka on eräänlainen olioväylä. Se mahdollistaa olioille läpinäkyvän palveluiden tarjoamisen ja palveluiden pyytämisen toisilta olioilta, jotka voivat olla paikallisia tai etäolioita verkossa. CORBAn väitetään olevan paras koskaan määritelty hajautusmenetelmä, mutta tosiasiassa CORBAn hyvyyden määrittelee sen toteuttavat tuotteet.

Mainitun kieliriippumattomuuden lisäksi CORBAlla on myös lukuisia muita etuja. ORB mahdollistaa staattisten metodikutsujen (engl. static invocation) lisäksi dynaamisen (engl. dynamic invocation) menetelmän, jossa kutsuttavat metodit voidaan selvittää vasta ajonaikana. Dynaamista menetelmää käytetään kuitenkin huomattavasti staattista menetelmää harvemmin. Kuhunkin CORBAn mukaiseen ORBiin liittyy rajapintavarasto (engl. Interface Repository), joka sisältää reaaliaikaista tietoa kaikista palveluista, metodeista ja niiden parametreistä. Näin CORBA on siis itsensä määritteleviä (self-describing) järjestelmä. Järjestelmän objektien sijainti on läpinäkyvä sovelluksille ja sovellusohjelmoijalle. CORBAssa on myös määritelty sisäänrakennettu turvallisuusmekanismi. Myös olemassaolevan koodin liittäminen CORBA-järjestelmään on saatu varsin yksinkertaiseksi.

CORBA 2.0 määrittelee ORBissa pakolliseksi GIOP:n (General Inter-ORB Protocol) ja IIOP:n (Internet Inter-ORB Protocol). Näistä GIOP on suunniteltu erityisesti ORBien väliseen kommunikointiin ja sen tulisi sijaita jonkin yhteyspohjaisen kuljetuskerroksen protokollan päällä. GIOP määrittelee mm. olioiden objektireferenssien, eli IORien (Interoperable Object Reference) formaatin. ORBin on muodostettava yksikäsitteinen IOR aina, kun olioviittauksia välitetään ORBin yli. IOR määrittelee siis olion yksikäsitteisesti ominaisuuksineen ja lähdekoneen IP-osoitteesta ja TCP-portista lähtien. IIOP määrittelee, kuinka GIOP-viestit siirretään TCP/IP-verkon yli.

4.3.2 Kommunikaatio CORBAssa

CORBAssa kommunikoinnin osapuolien välinen rajapinta määritellään IDL –kielellä (Interface definition language). IDL ei siis ole ohjelmointikieli, vaan määrittelykieli. Nämä IDL-rajapinnat käännetään määrittelyn jälkeen tarkoitusta varten tehdyillä kääntäjillä sopivalle ohjelmointikielelle.

Tyngät (engl. stubs) ja rungot (engl. skeletons) syntyvät IDL-rajapintamäärityksestä tehdystä käännöksestä ja näiden pohjalta toteutetaan asiakas ja palvelin. Tyngät ja rungot vastaavat etäkutsujen parametrien, palautusarvojen ja poikkeusten formaattien muuttamisesta prosessoinnin kannalta oikeaksi (engl. marshaling / unmarshaling). Tällaiset muunnokset tehdään aina tyngässä siirtoa varten lähetettäessä kutsua (engl. marshaling) ja rungossa prosessointia varten vastaanotettaessa kutsua (engl. unmarshaling). Vastaavasti palautusarvojen tai poikkeusten välittämisessä palvelimelta asiakkaalle tehdään muunnos siirtoa varten rungossa ja muunnos prosessointia varten tyngässä. Ohjelmoijalle jää siis asiakkaan toteutus ja CORBA-palvelimen, eli siis määritellyn rajapinnan toteutus.

Oliosovitin (Object Adaptor) määrittelee, kuinka etäobjekti aktivoidaan. Tämä voidaan tehdä joko luomalla uusi prosessi, luomalla uusi säie olemassaolevaan prosessiin tai käyttämällä uudelleen olemassaolevaa säiettä tai prosessia. CORBA-standardissa määritellään kahdentyyppisiä oliosovittimia. BOA (Basic Object Adaptor) aiheutti liian väljänä määrityksenä rajoitteita palvelimien siirrettävyyteen, jonka seurauksena määriteltiin POA (Portable Object Adaptor).

Kuvassa 6 on esitetty CORBA 2.0:n mukainen arkkitehtuuri, jossa on kuvattu staattisen ja dynaamisen kutsutavan edellyttämät komponentit. CORBA-tuotteet tarjoavat arkkitehtuurista ORBin toteutuksen ja sen palvelut. Lisäksi tuotteiden mukana on yleensä jonkinlainen IDL-kääntäjä.

Kuva 6: CORBA 2.0 -arkkitehtuuri.

CORBAn callback-menetelmän avulla palvelin voi kutsua asiakkaan metodeja. Nämä callback-kutsut on määriteltävä niin ikään IDL-rajapinnassa. Callback-palvelimien ja tavallisten CORBA-palvelimien ero on lähinnä siinä, että callback-kutsuja voi tehdä vasta, kun callback-palvelimen sisältävä asiakas on ensin ottanut yhteyttä varsinaiseen palvelimeen ja välittänyt callback-palvelimensa IORin sille. Sen sijaan palvelimen voi paikallistaa erilaisten ORBin määrittelemien palveluiden kautta (esim. nimipalvelu).

CORBA määrittelee useita palveluita ORBille, joista tärkeimpiä ovat nimipalvelu (engl. naming service), tapahtumapalvelu (engl. event service), kyselypalvelu (engl. query service), turvallisuuspalvelu (engl. security service, CORBASec) sekä ns. Trader-palvelu. Nimipalvelun avulla voidaan paikallistaa ja saada objektireferenssi palvelimeen sen nimen perusteella. Nimet voivat muodostua monitasoisesta hierarkiasta hakemistopolkujen tapaan.

Tapahtumapalvelu tarjoaa komponenteille mahdollisuuden rekisteröidä tai poistaa kiinnostuksensa tiettyjä tapahtumia kohtaan. Kyselypalvelulla voidaan hakea objekteja hakuoperaatioilla, jotka perustuvat SQL-lauseisiin (Structured Query Language). Turvallisuuspalvelu tarjoaa mahdollisuuksia tietoturvan toteuttamiseen järjestelmässä. Tätä käsitellään luvussa 4.3.3 tarkemmin. Trader-palvelua voisi verrata puhelinluettelon keltaisiin sivuihin, jossa oliot mainostavat palveluitaan.

4.3.3 CORBASec – CORBA Security Service

CORBA-standardissa määritellyn CORBASec-turvallisuuspalvelun tarkoituksena on tarjota tietoturva CORBA-järjestelmiin. Se kattaa käyttäjien ja olioiden autenttisuuden, autorisoinnin ja oikeuksien hallinnan, tiedon salaamisen, tiedon oikeellisuuden varmistamisen sekä salatun tiedon hallinnan.

Loppukäyttäjälle turvallisuuspalvelun käytön tulisi olla mahdollisimman näkymätön. Ohjelmoijan ei niin ikään tarvitse tuntea turvallisuuspalvelua tai huomioida sen käyttöä. CORBA 2.0 määrittelee kuitenkin tietoturvan toteuttamiseen tarkoitettuja sovellusohjelmointirajapintoja, joita sovellusohjelmoija voi käyttää. Sovellusohjelmoija voi näitä rajapintoja käyttäen suorittaa mm. suojattuja etäkutsuja. Tässä tapauksessa tietoturvan toteuttaminen ei ole enää sovellukselle näkymätöntä. Myös turvallisuuspalvelun skaalautuvuuteen on kiinnitetty huomiota. Sen tulisi toimia niin pienissä kuin laajoissakin järjestelmissä.

CORBASecin rajapinnat määrittelevät erilaisia palveluja tietoturvan alueilta, kuten autentikoinnin, sanoman suojauksen, pääsynvalvonnan, auditoinnin sekä ns. kiistämättömyyteen (engl. non-repudiation) liittyvät toiminnot. Pääsynvalvonnalla voidaan hallita olioiden ja palveluiden käyttöä. Tavallisesti tämä tapahtuu ORB-tasolla siten, että metodikutsun yhteydessä turvallisuuspalvelu tarkastaa kutsun suorittaneen olion pääsyoikeudet salattuun sisältöön ja itse kutsuun tarvittavat oikeudet. Auditoinnissa lokiin voidaan tallentaa, mitä palveluita on pyydetty ja mikä asiakas näitä on pyytänyt.

CORBASec sisältää turvallisuusmääritelmiä kolmella tasolla siten, että korkeampi taso sisältää enemmän toiminnallisuutta kuin edellinen. Taso 0 integroi käytännössä vain SSL:n CORBAan. Taso 1 tarjoaa edellä mainittujen tietoturva-aluiden ratkaisut kiistämättömyyttä lukuunottamatta. Taso 1 kattaa sovellukset, joille tietoturva ei näy. Taso 2 puolestaan kattaa sovellukset, jotka ovat tietoturvasta tietoisia ja se sisältää myös kiistämättömyysominaisuudet.

Kaikkien tietoturvamenetelmien toteuttamisen sijaan CORBASec nojautuu vahvasti olemassaoleviin turvallisuusmekanismeihin, kuten Kerberos v5 (luku 3.6), SESAME, SPKM tai SSL (luku3.2). Näitä käytetään GSS-APIa muistuttavan geneerisen APIn kautta. Tästä johtuen CORBASec omaa aina samat rajoitukset kuin sen alla oleva mekanismi. Mainittakoon, että joitain palveluita on toteutettu myös ORB-tasolla, kuten hallinta ja auditointi. Autentikoinnissa ja sanoman salauksessa käytetään kuitenkin täysin alemman kerroksen tarjoamia palveluita. CORBASec liittää CORBA-maailman alla sijaitsevaan turvallisuusratkaisuun kuvan 7 mukaisesti.

Kuva 7: CORBASec arkkitehtuurissa.

CORBASec määrittelee myös SECIOPin (Secure Inter-ORB Protocol), jonka tarkoituksena on sovittaa erilaiset CORBASec toteutukset yhteensopiviksi. SECIOP sijaitsee GIOP:n ja IIOP:n välissä. Käytännössä monet CORBA-sovellukset käyttävät SSL:ää, josta johtuen autentikointi ei onnistu oliotasolla. Koska SSL toimii ORB-tason alapuolella ja on socket-pohjainen, ei voida mitenkään autentikoida eri olioita ORBilla, joka käyttää SSL:n autentikoimaa sokettia.

CORBA Security Service -standardi on lähinnä suuri joukko vaatimuksia toteutukselle, mutta itse toteutukseen siinä ei juuri puututa. Monet toteutukset ovatkin paisuneet melko suuriksi ja raskaiksi. CORBASecissä yritetään ratkaista tietoturvaongelma monella tasolla. Niin autentikointi kuin sanomien salaus toteutetaan ORB-tason alapuolella ja varsinaisten tietoturvamenetelmien toteutusten erityispiirteet pyritään piilottamaan ORB-tasolta. Tämä taas aiheuttaa väistämättä ongelmia. Lisäksi mm. autentikointi ja autorisointi on CORBASecissä määritelty puutteellisesti Moni implementoija onkin kehitellyt tuotteisiinsa oman menetelmän, joka taas ei välttämättä ole yhteensopiva muiden valmistajien menetelmien kanssa. Näin ollen ainoa järkevä tapa pääsynvalvonnan toteutukseen on integroida se sovelluksen sisään.

Geneerisen turvallisuuspalvelun sijoittamista kerrosrakenteiseen väliohjelmistoon (engl. middleware) ja saavuttaen samalla siirrettävän, läpinäkyvän ja tehokkaan tietoturvaratkaisun pidetään lähinnä utopiana [Lang, s. 15]. Tästä huolimatta CORBASeciä ei pidetä käyttökelvottomana, joskin sen käyttö edellyttää vahvaa tuntemusta alla olevasta tietoturvamekanismista. CORBASecin ei uskota johtavan turvalliseen hajautettuun järjestelmään plug-in ratkaisuna, mutta sitä pidetään kuitenkin hyvänä työkalupakkina (engl. toolkit) turvallisuuden toteuttamiseen.

4.3.4 Visibroker ja muut CORBA-ohjelmistot

Kaupallisten ORBien markkinajohtajina ovat tällä hetkellä Borland Visibroker-tuotteellaan sekä Iona Orbix- ja OrbixWeb-tuotteillaan. Esimerkiksi Borlandin VisiBrokerissa on ohjelmisto, jolla voidaan IIOP-sanoma tunneloida HTTP:n sisään. Tunnelointi aiheuttaa aina viivettä, mutta palomuurien kannalta HTTP-tunneloinnin käyttö ei vaatisi IIOP:lle oman portin avaamista palomuurin. HTTP-sanoman voisi salata esimerkiksi SSL:llä. SSH-tunnelointia on niin ikään käytetty salaamaan CORBA-liikennettä. Tämä voidaan tehdä sovellukselle näkymättömästi. Tunnelointi ei kuitenkaan ole sovelluksen suorituskyvyn kannalta paras, eikä käytön kannalta kätevin vaihtoehto.

CORBA -standardiin on lisätty IIOP:n suojattu versio SSLIIOP. Nimensä mukaisesti IIOP salataan tällöin SSL:llä.

Borlandin Visibrokerin SSL Pack sisältää työkalut CORBA-yhteyksien suojaamiseen. Sen avulla voidaan mm. kuljettaa IIOP-sanomia HTTPS:n sisällä. Tällöin esimerkiksi CORBA-appletit eivät tarvitse sisäänrakennettua tietoturvaa. SSL Pack tukee myös QoP:tä (Quality of Protection) eli suojauksen laatua, jonka avulla sovellus voi ajon aikana valita sopivan suojaustason. SSL Pack sisältää tuen myös Internet- ja intranet-sertifikaateille.

Visibrokeriin on integroituna monipuolinen tietoturvapaketti (Borland Security Service), jonka mukana on myös toteutusesimerkkejä turvallisista asiakkaista ja palvelimista. Nämä esimerkit ovat nähtävissä myös Borlandin WWW-sivuilla (http://www.borland.com, Security Service Guide 4.5). Haittapuolena on Visibroker-lisenssin korkea hinta muihin toteutuksiin nähden.

Sovellukselle näkyvien tietoturvaratkaisujen käyttöönotto olemassaolevissa järjestelmissä tuottaa väistämättä ohjelmakoodiin muutoksia ja uusia käännöksiä. Olemassaolevan järjestelmän ollessa kyseessä onkin syytä kartoittaa tarkkaan tietoturvavaatimukset ja selvittää, voidaanko vaatimukset täyttää jollain sovelluksille näkymättömällä tavalla kuten esimerkiksi SSH-tunneloinnilla. CORBAan voidaan tietoturva tuottaa myös ulkoisella tietoturvaohjelmistolla, kuten esimerkiksi Phaosin SSLavalla (katso luku 4.6).

Ilmaisista tuotteista mm. JavaORBissa on toteutettu tietoturvaominaisuuksia JavaORB OSS:ssä (Object Security Service). Toteutus on CORBASec-yhteensopiva ja se kattaa kyseisestä standardista kaiken kiistämättömyyttä lukuunottamatta. JavaORB OSS sisältää myös graafisen käyttöliittymän turvallisuuden hallintaan JavaORBissa. JavaORBia voi käyttää vapaasti myös kaupallisissa sovelluksissa. Se on ns. open source -toteutus.

4.4 RPC (Remote Procedure Call) ja DCE (Distributed Computing Environment)

RPC kuuluu sokettiohjelmoinnin ohella hajautusmenetelmien esi-isiin. RPC:n etäproseduurikutsut ovat hyvin samankaltaisia paikallisten aliohjelmakutsujen kanssa. Etäkutsun suorittamiseen tarvitaan kutsuttavaa palvelinta ja kutsun suorittavaa asiakasta. Palvelin voi tukea useampaa versiota etäohjelmasta. DCE-standardi on RPC:hen perustuva hajautusmenetelmien kokoelma.

4.4.1 RPC-arkkitehtuuri

RPC-protokollan toteutuksesta riippuen asiakas voi suoritettavan etäkutsun aikana suorittaa paikallisesti tehtäviä tai vastaavasti palvelin voi luoda kutsulle oman prosessin, jolloin palvelin voi vastaanottaa uuden kutsun, vaikka edellisiä kutsuja olisikin vielä suorituksessa. Useimmat toteutukset eivät näitä ominaisuuksia kuitenkaan tue.

RPC-järjestelmässä asiakkaan ja palvelinpään tyngät (engl. stub) generoidaan käännettäessä asiakastoteutuksen koodia. RPC-järjestelmän arkkitehtuuri on esitetty kuvassa 8.

Kuva 8: RPC-arkkitehtuuri.

Paikallisesti suoritettavaan aliohjelmakutsuun verrattuna etäkutsuissa on huomioitava verkon virheistä aiheutuvat poikkeukset, globaalit muuttujat ja niiden sivuvaikutukset, suorituskyky sekä autentikointi. RPC on menetelmänä vanhanaikainen, eikä se skaalaudu kovin hyvin olioympäristöön. Sillä on kuitenkin ollut merkittävä asema hajautusmenetelmien kehittymisessä.

4.4.2 Kommunikointi RPC:ssä

RPC:ssä kommunikointi tapahtuu RPC-protokollan avulla, joka voidaan toteuttaa usean erilaisen kuljetuskerroksen protokollan päälle. RPC-protokolla ei ota kantaa, miten sanoma siirretään lähettäjältä vastaanottajalle, eikä siinä toteuteta siirron luotettavuutta takaavia elementtejä. Tästä johtuen saatetaan joissain sovelluksissa tarvita tietoa käytettävästä kuljetusprotokollasta.

RPC-sanoma voi olla joko kutsu (engl. call) tai vastaus (engl. reply). Kukin RPC-sanoma sisältää tapahtumatunnisteen (engl. transaction id) ja viestityypin. Kutsussa on lisäksi tunnisteet kutsuttavalle etäohjelmalle, ohjelman versiolle sekä aliohjelmalle. Näiden kenttien jälkeen kutsu sisältää autentikointiin liittyvää informaatiota, joka käsittää valtakirjan (engl. authentication credentials) ja vahvistajan (engl. authentication verifier).

Vastausviesti sisältää tiedon suorituksen onnistumisesta. Vastausviestissä on aina autentikointi-informaatiota. Onnistuneessa suorituksessa viestissä on proseduurikohtainen palautusarvo ja virheen sattuessa virhekoodi. Palvelin voi hylätä etäkutsun kahdesta syystä: autentikointi ei onnistunut tai palvelimessa ei ole yhteensopivaa RPC-protokollan versiota asiakkaan kanssa.

RPC-kutsun suoritus vastaa hyvin paljon muiden hajautusmenetelmien etäkutsuja. RPC-kutsun syntaksi vastaa normaalia aliohjelmakutsua, mutta sen suoritus etenee seuraavasti:

1. Paikallistetaan palvelin kutsua varten.

2. Kutsuun liittyvät argumentit muutetaan (engl. marshal) sopivaan muotoon siirtoa varten.

3. Kutsu siirretään asiakkaalta palvelimelle jonkin verkkoprotokollan avulla.

4. Kutsun argumentit muutetaan (engl. unmarshal) palvelinpäässä sopiviksi suoritusta varten.

5. Aliohjelma suoritetaan.

6. Palautusarvo tai poikkeus muutetaan sopivaksi siirtoa varten.

7. Palautusarvo (tai poikkeus) siirretään asiakkaalle.

8. Asiakas muuttaa palautusarvon (tai poikkeuksen) sopivaan muotoon prosessointia varten.

4.4.3 Autentikointi RPC:ssä

RPC-protokollaan voidaan liittää autentikointimekanismi, jolla asiakas identifioi itsensä palvelimelle ja päin vastoin. Autentikoinnissa voidaan käyttää toteutuksesta riippuen esimerkiksi DES- ja Diffie-Hellman -menetelmiä (katso luvut 2.1.1 ja 2.3.1).

DES-autentikoinnissa asiakas generoi RPC-istunnon alussa muunnosavaimen (engl. conversation key), joka siirretään myös palvelimelle. Autentikoinnissa tällä muunnosavaimella salataan autentikoinnissa käytettävän valtakirjan varmistuskenttä, jolla taataan asiakkaan identiteetti. Muunnosavaimen vaihtoon voidaan käyttää Diffie-Hellman -menetelmää. Valtakirjan ohella asiakas lähettää palvelimelle aikaikkuna-arvon (engl. window), joka määrää valtakirjan voimassaoloajan lähetyshetkestä eteenpäin. Varmistuskenttä sisältää aikaleiman, jonka palvelin tarkastaa yhdessä aikaikkunan arvon kanssa. Asiakkaan ja palvelimen kellot on siis oltava synkronoitu esimerkiksi NTP:llä (Network Time Protocol). Palvelin lähettää vastauksessaan asiakkaalle myös kellonajan (asiakkaalta saatu aikaleiman aika vähennettynä sekunnilla), jonka asiakas tarkastaa.

RPC-standardissa on määritelty myös UNIX-tyyppinen autentikointi, jossa tietoturvaominaisuudet ovat kuitenkin heikkoja. Varsinaisen liikenteen salaamiseen ei RPC-standardi ota kantaa.

4.4.4 DCE (Distributed Computing Environment)

OSF:n (Open Software Foundation) DCE on teollisuusstandardi, joka on kokoelma hajautusmenetelmistä. DCE:n juuret ovat 90-luvun alussa ja se tarjoaa täyden hajautusinfrastruktuurin, johon sisältyy tietoturvaominaisuuksia, nimipalvelu sekä skaalautuva malli hajautettujen käyttäjien, palvelujen ja tietojen organisointiin. DCE perustuu RPC-menetelmään ja se toimii yleisimpien käyttöjärjestelmien päällä. DCE tarjoaa myös mahdollisuuden tiedostojen jakamiseen hajautetun tiedostojärjestelmän kautta. Poikkeuksena CORBAsta DCE tarjoaa referenssitoteutuksen DCE-standardista.

Myös DCE:ssä rajapinnat määritellään IDL-kielellä. Rajapintamäärittelyt kattavat kutsut parametreineen, palautusarvoineen ja poikkeuksineen. DCE:n IDL perustuu C-kieleen, kun CORBAn IDL perustuu enemmän C++ -kieleen. Tästä johtuen DCE:ssä ei voida rajapintamäärittelyissä käyttää esimerkiksi perintää tai polymorfismia. Myös DCE:ssä IDL-kääntäjä generoi asiakas- ja palvelintyngät, jotka vastaavat parametrien, palautusarvojen ja poikkeusten formaattien muunnoksista (engl. marshaling / unmarshaling).

DCE:n nimipalvelu perustuu CORBAn tavoin nimihierarkiaan. Puurakenteisessa nimihierarkiassa alipuina ovat tavallisesti palvelimet, käyttäjät sekä tiedostot. Puun solmuja kutsutaan soluiksi (engl. cell). Nimet ovat hyvin samankaltaisia hakemistopolkujen kanssa. Nimipalveluita voidaan suorituskyvyn parantamiseksi käyttää useampia, jolloin nimipalvelimet keskustelevat toistensa kanssa.

DCE:n mielenkiintoisin ominaisuus muihin tutkielmassa esiteltyihin hajautusmenetelmiin on hajautettu tiedostojärjestelmä (Distributed File System). Se kokoaa solun kaikkien isäntäkoneiden tiedostot yhdeksi nimiavaruudeksi.

DCE ei ole yhtä tunnettu edellä esitettyihin hajautusmenetelmiin verrattuna, mutta sillä on toteutettu lukuisia merkittäviä sovelluksia. Suomessa mm. Helsingin Puhelin Oy:n järjestelmissä on käytetty hyväksi DCE-menetelmää. Lisäksi seuraavana esiteltävä DCOM perustuu DCE:iin.

4.4.5 Tietoturva DCE:ssä

DCE:n tietoturva kattaa autentikoinnin, autorisoinnin ja yksityisyyden hajautetussa ympäristössä. Kullakin DCE:n solulla on oma turvallisuuspalvelu (Security Service), joka koostuu kolmesta pääkomponentista. Autentikointipalvelu (Authentication Service) identifioi käyttäjät ja palvelimet. Lisäksi se jakaa lippuja (engl. tickets) palveluita tarvitseville asiakkaille (engl. principles). Autentikointitapahtuma on samankaltainen Kerberos-järjestelmässä tapahtuvan autentikoinnin kanssa.

Oikeuspalvelu (Privilege Service) vastaa autorisoinnista, eli siitä mitä asiakkaat ovat oikeutettuja tekemään. Oikeuspalvelu perustuu oikeusattribuuttisertifikaatteihin (Privilege Attribute Certificate, PAC), jotka kuljetetaan palvelimelle lipun sisässä. Rekisteröintipalvelu (Register Service) ylläpitää tietokantaa turvallisuusinformaatiosta.

Tiedon salaus DCE:ssä perustuu salaisen avaimen menetelmiin (DES ja MD5; katso luvut 2.1.1 ja 2.2). Turvallisuuspalvelulla voidaan nimipalvelun tapaan toteuttaa kuormituksen hallintaa. Se on integroitu nimipalveluun ja hajautettuun tiedostojärjestelmään. DCE:n turvallisuuspalvelun käyttäminen ei näy sovellukselle eikä sovellusohjelmoijan tarvitse olla siitä tietoinen.

4.5 DCOM (Distributed Component Object Model)

DCOM on Microsoftin COM-arkkitehtuuriin (Component Object Model) pohjautuva hajautusmenetelmä. Hajautus perustuu RPC-tekniikkaan ja DCE:hen. DCOM sisältyy Windows-käyttöjärjestelmiin NT:stä lähtien ja se onkin alunperin vain Windows-pohjaisia järjestelmiä varten kehitetty. Nykyään DCOMista on kuitenkin saatavilla toteutuksia myös UNIX-, Linux- ja Solaris-alustoille. DCOM-järjestelmä voidaan toteuttaa useilla ohjelmointikielillä, kuten C++, Java, Object Pascal ja Visual Basic.

4.5.1 DCOM-arkkitehtuuri

COM-objektit jaetaan kolmeen luokkaan. In-Process -luokan komponentti ladataan luontivaiheessa asiakkaan muistiavaruuteen. Tällöin kommunikointi asiakkaan ja komponenttien välillä on mahdollisimman tehokasta. Local-luokan komponentit ovat paikallisia palvelinkomponentteja. Ne sijaitsevat siis samassa koneessa asiakkaan kanssa, mutta eri prosessissa. Remote-luokan komponentit, eli etäkomponentit sijaitsevat eri koneessa asiakkaan kanssa ja kommunikointi tapahtuu verkon yli.

COM-objektien välinen kommunikointi tapahtuu tarkkaan määriteltyjen rajapintojen kautta. Kukin COM-objekti toteuttaa ainakin IUnknown-rajapinnan, jolla objektilta voidaan kysellä sen toteuttamia muita rajapintoja. Olioiden toteuttamat rajapinnat identifioidaan yksikäsitteisellä GUIDillä (Globally Unique Identifier).

DCOM-palvelin voi tukea useita rajapintoja. Asiakkaan on saatava osoitin johonkin palvelimen rajapintaan, ennen kuin kommunikointi voidaan aloittaa. Tämän jälkeen kommunikointi tapahtuu samoin, kuin jos palvelinolio sijaitsisi samassa prosessissa asiakkaan kanssa. Kommunikointi perustuu ORPC-protokollaan (Object Remote Procedure Call), joka sijaitsee RPC:n päällä ja toimii COMin ajonaikaisten palveluiden kanssa. ORPC vastaa CORBAn IIOP:tä. DCOM tukee CORBAn tavoin staattisia ja dynaamisia metodikutsuja. DCOMin yleinen arkkitehtuuri on esitetty kuvassa 9.

Kuva 9: DCOM-arkkitehtuuri.

Rajapinnat määritellään IDL-tiedostossa MIDL:llä (Microsoft IDL). Rajapinnasta kääntäjä generoi proxyn ja tyngän (engl. stub) koodin. Dynaamisia metodikutsuja varten olioiden ominaisuudet ja käyttäytyminen määritellään ns. tyyppikirjastoissa (engl. type libraries), joita voidaan kysellä Idispatch-rajapinnan kautta. Rajapintojen lisäksi myös kukin olio saa yksikäsitteisen tunnisteen, CLSID:n. Sovellusohjelmoijan on rajapintamääritysten lisäksi toteutettava asiakas ja rajapinnan (tai rajapinnat) toteuttava palvelin.

Ominaisuudet ovat DCOMissa jokseenkin samat kuin CORBAssa, mutta lähtökohdat ja toteutus poikkeavat toisistaan jonkin verran. Varsinkin Microsoft-spesifisyys on jättänyt DCOMia CORBAn varjoon.

4.5.2 DCOMin tietoturva

Kuten koko DCOM, myös tietoturvaratkaisut DCOMissa perustuvat Windows NT -käyttöjärjestelmään. Tietoturvamallissa itse tietoturvaratkaisut voidaan piilottaa täysin asiakkaalta ja palvelimelta. Tietoturva-asetukset konfiguroidaan tällöin järjestelmänvalvojan toimesta.

DCOM tarjoaa NT:n tapaan käyttöoikeuslistoja (Access Control List, ACL). DCOMin käyttöoikeuslistat koskevat tiedostojen sijaan komponentteja. Listat määrittelevät käyttäjä tai käyttäjäryhmät, jotka ovat oikeutettuja käyttämään eri komponentteja. Asiakkaan kutsuessa palvelinta käyttöjärjestelmältä saadaan käyttäjänimi, jonka mukaan käyttöoikeudet tarkastetaan. Käyttäjän oikeuksien tarkastelu voidaan toteuttaa myös itse sovelluksessa, jos esimerkiksi halutaan sallia joitain palveluja vain tietyille käyttäjäryhmille. Tällöin sovellus voi pyytää käyttäjäinformaatiota DCOM-komponenteilta.

Windows NT tarjoaa autentikointiin NTLM-protokollan, jonka Kerberos v5 –protokolla (katso luku 3.7) korvannut Windows 2000 -käyttöjärjestelmässä. Windows NT:n tietoturvasta löytyy myös SSL- ja PCT -tuki (katso luvut 3.2 ja 3.3). Windows 2000:een on lisätty myös julkisen avaimen menetelmiä. Tietoturvan liittäminen DCOMiin on pyritty toteuttamaan Windows NT:n tietoturvakehyksen puitteissa ilman, että siihen tarvitaan ulkoisia ohjelmia.

4.6 SSLava

Hajautettuihin järjestelmiin voidaan tietoturvaominaisuuksia liittää myös ulkoisilla tietoturvaohjelmistoilla. Tässä luvussa käsitellään Phaosin SSLava-tuotetta ja sen sijoittumista hajautettuun arkkitehtuuriin. SSLava on kaupallinen tuote ja lisenssien hinnat alkavat noin 3500 eurosta (tilanne elokuussa 2001). SSLava on tarkoitettu Java-ympäristöön. SSLava tarjoaa luokka kirjastot sokettien suojaamiseen, mutta sitä on käytetty myös CORBA- ja RMI-pohjaisissa järjestelmissä.

SSLava 2.1:ssä on tuki SSL 3.0 -standardille (katso luku 3.2), TLS:lle (katso luku 3.5), X.509-sertifikaateille (katso luku 2.4) ja HTTPS:lle (katso luku 3.6). SSLava on itse asiassa Phaos e-Security Platform -tuotteen komponentti. Phaos e-Security Platform perustuu Phaos Security Engine –kirjastoon, joka sisältyy myös SSLavaan. Security Engine sisältää seuraavat salausalgoritmit:

· DSA (katso luku 2.3.3),

· RC4 ja RC2 (katso luku 2.1.3),

· Blowfish (katso luku 2.1.4),

· DES ja triple-DES (katso luvut 2.1.1 ja 2.1.2) sekä

· RSA (katso luku 2.3.2).

SSLava tarjoaa sovelluskehitykseen työkalupakin, jossa sovelluohjelmointirajapintojen avulla voidaan tietoturva liittää sovellukseen. SSLava on siis joukko Javan luokkakirjastoja ja on siten sovellukselle näkyvä tietoturvaratkaisu. Kuvassa 10 on esitetty SSLavan sijoittuminen sovellusarkkitehtuuriin.

Kuva 10: SSLava sovellusarkkitehtuurissa.

5 Yhteenveto

Monitasoisella ohjelmistoarkkitehtuurilla voidaan parantaa huomattavasti tietoturvaa, mutta sen toteuttaminen hajautettuun järjestelmään ei välttämättä ole yksiselitteinen tehtävä. Tietoturvan maksimoimiseksi tulee asiaan kiinnittää huomiota jo suunnittelu- ja toteutusvaiheessa. Arkaluontoinen ohjelmakoodi tulisi sijoittaa turvalliseen paikkaan, eikä esimerkiksi käyttöliittymän yhteyteen.

Etenkin hajautetuissa järjestelmissä korostuu tietoturvan suunnittelun tärkeys. Tietoturvaratkaisuja valittaessa ja toteutettaessa tulisi määritellä mahdollisimman tarkkaan tietoturvan taso. Järjestelmän vaatimuksia määritettäessä on syytä selvittää, tarvitaanko esimerkiksi autentikointia käyttäjätasolla vai jopa etäkutsuja suorittavien komponenttien tasolla saakka. Lisäksi tulisi selvittää, missä liikenne tulisi salata, missä arkaluontoinen informaatio liikkuu sekä miten arkaluontoista siirrettävä data on ja mikä on riittävä salauksen taso. Koska tietoturvan liittäminen järjestelmään tapahtuu aina suorituskyvyn kustannuksella on näihin kysymyksiin paneuduttava huolella.

Mikäli järjestelmä edellyttää olioiden autentikointia, on käytännössä mahdotonta löytää tietoturvaratkaisuja, jotka ovat sovellukselle näkymättömiä. Etenkin olemassaolevien järjestelmien suojaamisessa tulisi kiinnittää erityistä huomiota tietoturvaratkaisun käyttöönottoon. Jos ratkaisu on sovelluksille näkyvä, tarvitaan järjestelmään muutoksia kooditasolla asti. Tämä taas johtaa uusiin käännöksiin ja versionhallinnan hankaloitumiseen.

Vaikka itse tietoturvaratkaisuissa (kuten SSL ja SSH) lähtökohdat saattavat olla hieman erilaisia, löytyy niiden taustalta kuitenkin jokseenkin samat algoritmit. Tietoturvaratkaisua valittaessa onkin syytä kiinnittää erityistä huomiota siihen, mitä eri tuotteet ja toteutukset käsittävät, sillä monet standardit määrittelevät useita algoritmeja valinnaisiksi toteutuksiin. Tiedon salaaminen perustuu salausavaimen käyttöön ja merkittävin yksittäinen mittari salauksen vahvuuteen on salausavaimen pituus. Täysin turvallista salausavaimeen perustuvaa algoritmia ei ole olemassakaan. Raa’an voiman periaatteella voidaan periaatteessa selvittää salainen avain. Selvittäminen edellyttää kuitenkin laskentatehon voimakasta lisäämistä avaimen pituuden kasvaessa.

SSL on hajautetuissa järjestelmissä selvästi yleisin menetelmä tietoturvan toteuttamiseen, joten SSH:ta käsiteltiinkin tutkielmassa lähinnä vaihtoehtoisena, hieman erilaisena tietoturvan tarjoajana. On kuitenkin olemassa merkittäviäkin järjestelmiä, joissa tieto salataan nimenomaan SSH-tunneloinnilla.

Tutkielmassa esitettyjen tietoturvaratkaisujen lisäksi tietoturvaa voidaan toteuttaa esimerkiksi verkkotasolla IPSec-laajennuksella, joka tuo IP-protokollaperheeseen tietoturvaominaisuuksia verkkotasolle. IPSec salaa IP-liikenteen, joten se on käyttökelpoinen ratkaisu verkkoliikenteen suojaamiseen myös hajautetuissa järjestelmissä. IPSec-tuotteita on saatavilla mm. SSH Communicationsilta.

Hajautetuissa järjestelmissä on usein olennaisena osana myös tietokantayhteys, joka voidaan toteuttaa esimerkiksi JDBC:llä (Java Database Connectivity) tai ODBC:llä (Open Database Connectivity). Näihin on olemassa omat tietoturvamääritykset, jotka perustuvat kuitenkin edellä esitettyihin menetelmiin.

Myös verkon infrastruktuurilla voidaan karsia riskejä etenkin ulkoa päin tulevien hyökkäysten osalta. Verkkoympärisöt voivat hajautetuissa järjestelmissä vaihdella täysin suljetuista lähiverkoista VPN:iin (Virtual Private Network) ja aina Internetiin saakka.

Lähteet

Alireza A., Lang U., Padelis M., Schreiner R. and Schumacher M., "The Challenges of CORBA Security", University of Cambridge, saatavilla PDF-muodossa http://www.cl.cam.ac.uk/~ul201/Springer.pdf, 2000.

OMG, “CORBA Security Service Specification v1.2”, OMG, saatavilla WWW-sivuilta PDF-muodossa http://cgi.omg.org/cgi-bin/doc?formal/98-12-17.pdf, 1998.

Counterpane Internet Security, Inc., Blowfish Encryption Algorithm, saatavilla HTML-muodossa http://www.counterpane.com/blowfish.html, 2001.

Dierks T. and Allen C., " RFC 2246- The TLS Protocol Version 1.0", IETF, saatavilla HTML-muodossa http://www.ietf.org/rfc/rfc2246.txt, 1999.

Freier Alan, Karlton Philip and Kocher Paul C, "The SSL Protocol Version 3.0", INTERNET DRAFT, saatavilla HTML-muodossa http://home.netscape.com/eng/ssl3/draft302.txt, 1996.

Gopalan Suresh Raj, "A Detailed Comparison of CORBA, DCOM and Java/RMI", saatavilla HTML-muodossa http://www.execpc.com/~gopalan/misc/compare.html, 1998.

Horstman Markus and Kirtland Mary, "DCOM Architecture", Microsoft, saatavilla HTML-muodossa http://www.msdn.microsoft.com/library/backgrnd/html/msdn_dcomarch.htm, 1997.

Sun, “JSSE Reference Guide for the J2SDK v 1.4”, Sun Microsystems, saatavilla HTML-muodossa http://java.sun.com/j2se/1.4/docs/guide/security/jsse/JSSERefGuide.html.

Kerttula Esa, "Tietoturva Tietoverkoissa", Liikenneministeriö, Helsinki, 1998.

Kohl J. and Neuman C., September, "RFC 1510 - The Kerberos Network Authentication Service v5", IETF, saatavilla WWW-sivulta http://www.ietf.org/rfc/rfc1510.txt, 1993.

Lang Ulrich, Gollmann Dieter, Schreiner Rudolf, "Security Attributes in CORBA", University of Cambridge, saatavilla PDF-muodossa http://www.cl.cam.ac.uk/~ul201/SecAttr.pdf, 2001.

Linn J., "RFC 2743 - Generic Security Service Application Program Interface Version 2, Update 1", IETF, saatavilla WWW-sivulta http://www.ietf.org/rfc/rfc2743.txt, 2000.

Mattila Marko, "TLS", Tampereen Teknillinen Korkeakoulu, saatavilla WWW-muodossa http://www.cs.tut.fi/~mtm/83593/tls1.html, 1999.

Network Working Group, "RFC 1057 - RPC: Remote Procedure Call Protocol specification version 2", IETF, saatavilla WWW-sivulta http://www.ietf.org/rfc/rfc1057.txt, 1988.

Orfali Robert and Harkey Dan, "Client / Server Programming with Java and CORBA - 2^nd ed.", Wiley Computer Publishing, USA, 1998.

Rescorla E., "RFC 2818 HTTP Over TLS", IETF, saatavilla WWW-sivulta http://www.ietf.org/rfc/rfc2818.txt, 2000 .

Sun Microsystems,"Advanced Java Programming - Student Guide", Sun Educational Services, 2001.

Weiss Michael, Johnson Andy and Kiniry Joe, "Distributed Computing: Java, CORBA, and DCE" , Open Software Foundation, saatavilla HTML-muodossa http://www.inf.upol.cz/java/java_rpt/corba.htm - 6856, 1996.

Ylönen Tatu, Kivinen Tero, Saarinen Markku-Juhani O., Rinne Timo J., Lehtinen Sami, "SSH Protocol Architecture", SSH Communications Security, saatavilla WWW-sivulta http://www.ssh.com/tech/archive/secsh/architecture.txt, 2001.

Ylönen Tatu, Kivinen Tero, Saarinen Markku-Juhani O., Rinne Timo J., Lehtinen Sami"SSH Transport Layer Protocol", SSH Communications Security, saatavilla WWW-sivulta http://www.ssh.com/tech/archive/secsh/transport.txt, 2001.

Ylönen Tatu, Kivinen Tero, Saarinen Markku-Juhani O., Rinne Timo J., Lehtinen Sami "SSH Authentication Protocol", SSH Communications Security, saatavilla WWW-sivulta http://www.ssh.com/tech/archive/secsh/userauth.txt, 2001.

Ylönen Tatu, Kivinen Tero, Saarinen Markku-Juhani O., Rinne Timo J., Lehtinen Sami, "SSH Connection Protocol", SSH Communications Security, saatavilla WWW-sivulta http://www.ssh.com/tech/archive/secsh/connect.txt, 2001.

Open Group, ”The Open Group Portal to the World of DCE”, saatavissa WWW-sivulta osoitteesta http://www.opengroup.org/dce/, Open Group, 2001.