Kari Aho

Ryhmälähetysten salaus ja salausavainten hallinta

Tietotekniikankandidaatintutkielma16. tammikuuta 2006

Jyväskylän yliopisto

Tietotekniikan laitos

Jyväskylä

Tekijä: Kari AhoYhteystiedot: kari.aho@cc.jyu.fiTyön nimi: Ryhmälähetysten salaus ja salausavainten hallintaTitle in English: Encrypton and key management in multicastTyö: Tietotekniikan kandidaatintutkielmaSivumäärä: 25Tiivistelmä: MSEC1-työryhmä on luonut ryhmälähetyksiä varten joukon dokument-teja, joiden avulla voidaan luoda turvallinen yhteydenpito ryhmälähetyksissä. Nä-mä dokumentit sisältävät määrityksiä niin laitteistojen fyysisistä arkkitehtuureis-ta kuin avaintenhallinnastakin. Tässä tutkielmassa paneuduttiin edellä mainittujendokumenttien sisältöön ja eri vaihtoehtoihin siitä, kuinka ryhmälähetyksien salausja salausavainten hallinta voidaan toteuttaa.English abstract: MSEC-workgroup has created a group of documents concerningencryption of multicast traffic and key management in that environment in orderto create secure communication in multicast. In this thesis effort was put into goingthrough those documents and creating a general view of what kind of alternativesthere is to create secure multicast communication.Avainsanat: tietotekniikka, kandidaatintutkielma, ryhmälähetys, avaintenhallinta,salaus, MSEC-työryhmä, arkkitehtuuriKeywords: information technology, Bachelor’s thesis, multicast, key management,encryption, MSEC-workgroup, architecture

1Multicast security

Sisältö

1 Johdanto 1

2 Ryhmälähetys 1

3 MSEC-työryhmä 2

4 Ryhmälähetyksen turvallisuusarkkitehtuuri 2

5 Ryhmälähetysten avaintenhallinta-arkkitehtuuri 5

6 Tulkinta-alue GDOI 7

7 Multimedian salausavaimet 97.1 ECC Algoritmit MIKEY:lle . . . . . . . . . . . . . . . . . . . . . . . . . 117.2 HMAC-todennettu diffie-hellman MIKEY:lle . . . . . . . . . . . . . . 127.3 Lisämoodi MIKEY:n avainten jakamiseen: MIKEY-RSA-R . . . . . . . 127.4 Yleisen hyötykuorman laajennus MIKEY:ssa . . . . . . . . . . . . . . 13

8 Ryhmäavainten jakoprotokolla 13

9 Turvallisuuskäytäntöjen avaintenhallintaprotokolla 14

10 Ryhmäpolitiikkapoletti 17

11 RSA/SHA-1 allekirjoituksien käyttö ESP:n ja AH:n sisällä 18

12 Tehohäviötön todentaminen 1812.1 TESLA:n käyttö SRTP:ssä . . . . . . . . . . . . . . . . . . . . . . . . . 19

13 Yhteenveto 19

Viitteet 21

i

1 Johdanto

Tutkielman tarkoitus on tarkastella ryhmälähetyksien salausta ja salausavainten hal-lintaa yleisellä tasolla, että saataisiin kuva siitä, mitä vaaditaan turvatun yhteyden-pidon luomiseen esimerkiksi laajakaistaliittymien kautta toteutettaville IPTelevisio-palveluille.

Palveluiden laadun hallintaa laajakaistaverkoissa tutkitaan muun muassa Jyväs-kylän yliopiston PalHaLa-tutkimusprojektissa[1], jonka yhtenä osana on tutkia juu-ri laajakaistaliittymien soveltuvuutta kyseisille IPTV-palveluille, sekä palveluidenja verkon hallintaa kyseisessä ympäristössä. Edellä mainittujen palveluiden toteut-tamiseksi onkin tarvetta luoda yleiskatsaus IETF:n2 MSEC-työryhmän tuotoksistaja nykytilasta multicastin eli ryhmälähetyksen salauksesta ja salausavainten hallin-nasta. Yleiskatsaus tähän tutkiemaan on tehty vuoden 2005 loppuun mennessä val-mistuineiden MSEC-työryhmän dokumenttien pohjalta.

2 Ryhmälähetys

Ryhmälähetyksellä (engl. multicast) tarkoitetaan lähetysmuotoa, jossa lähetetään tie-toa kyseistä tilannetta varten luodun ryhmän jäsenille. Erona täsmälähetykseen (engl.unicast) ja yleislähetykseen (engl. broadcast) on, että lähettäjä ei lähetä pakettia kuinkerran yhdellä IP-osoitteella identifioitavalle kohderyhmälle, joka koostuu yhdestätai useammasta jäsenestä. Reitittimet monistavat paketin myöhäisimmissä mahdol-lisissa risteyskohdassa, jotka on lähimpänä paketin kaikkia vastaanottajia. Ryhmä-lähetyksen suurimpana etuna onkin edellä mainitusta seikasta johtuva verkon kuor-mittumisen ja reitityksien määrän huomattava pieneneminen verrattuna esimerkik-si täsmälähetykseen, jossa jokainen paketti pitäisi lähettää ja reitittää erikseen jokai-selle vastaanottajalle.

Hieman pintaa syvemmältä katsottuna huomataan, että Internet protokollan tur-vallisuusarkkitehtuurin turvallisuuspalvelut kuvaavat pääasiassa palveluita ja se-mantiikkaa IP-paketeille, jotka ovat suunnattuja täsmälähetyksille. Kyseisiä turvalli-suuspalveluita voidaan kuitenkin käyttää ryhmälähetyksien IP-pakettien tunneloi-miseen siten, että tunneli on aina muodostettu pareittain kahden IPsec-laitteen vä-lille, mutta tämä ei ole kovin tehokasta. Edellä mainitusta syystä Brian Weis, GeorgeGross ja Dragan Ignjatic ovat esittäneet ’Multicast Extensions to the Security Arc-hitecture for the Internet Protocol’ -dokumentissa [16] laajennuksia Internet proto-kollan turvallisuusarkkitehtuuriin, jotka mahdollistavat ryhmälähetysosoitteen IP-

2Internet Engineering Task Force

1

paketteihin. Ryhmälähetysosoitteen mahdollistaminen tuo takaisin aiemmin maini-tussa tunnelointitavassa menetetyn tehokkuuden.

3 MSEC-työryhmä

MSEC-työryhmän perustamisen tarkoitus oli luoda standardisoituja protokollia, jot-ka määrittelevät ryhmälähetyksien salausta. Käytännössä työryhmän tarkoitus onkeskittyä lähinnä sellaisiin ryhmälähetystilanteisiin, joissa on yksi luotettu lähde, se-kä suuri määrä tiedon vastaanottajia. (Ryhmälähetys voidaan toteuttaa myös monelta-monelle yhteytenä.)

Työryhmän kehittämien ratkaisujen on kyettävä selviytymään hyvin dynaami-sista ryhmistä eli tilanteista, joissa jäsenet saattavat vaihtua jatkuvasti. On siis taat-tava, että vain oikeutetuilla jäsenillä on pääsy ryhmään ja sen tietoihin, sekä lisäksiryhmän jäsenien on pystyttävä todentamaan lähetetty data niin kuin myös sen läh-de. Yhtenä tavoitteenaan työryhmä pitää myös suojautumista palvelunestohyök-käyksiä (DoS3) vastaan.

MSEC-työryhmän[2] päämääränä on luoda ainakin seuraavanlaiset dokumentit,joiden pohjalta voidaan rakentaa useille eri sovelluksille sopivat turvallisuusasetuk-set:

• RFC:t4 eli asiakirjat, jotka kuvaavat turvallisuusvaatimuksia, sekä turvallisuusark-kitehtuuria ryhmälähetyksille.

• RFC:t, jotka kuvaavat ryhmäavaintenhallinta- ja ryhmäpolitiikka-arkkitehtuureja.

• Useita RFC:itä, joissa kuvataan määritykset protokollille, jotka toteuttavat läh-teen tunnistamisen, ryhmäavainten, sekä ryhmäpolitiikan hallinnan.

Jatkossa käsitellään muutamia edellä mainittuja MSEC-työryhmän luomia doku-mentteja. Dokumentit ovat niin kehitysasteella olevia Internet-drafteja, kuin myösvalmistuneita määrityksiä, eli RFC:itä.

4 Ryhmälähetyksen turvallisuusarkkitehtuuri

Ryhmälähetyksien salauksessa pitää ottaa huomioon monia lähtökohtia, joita MSEC-työryhmä on lähtenyt erittelemään maaliskuussa 2004 valmistuneessa RFC-dokumentissa[4].

3Denial of Service4Request for Comments

2

Dokumentissa on kuvattu ryhmälähetyksien yleinen arkkitehtuuri siitä, millai-sia turvallisuuspalveluita tarvitaan turvaamaan suuret ryhmälähetysryhmät. Arkki-tehtuurin ratkaisut toimivat myös pienemmissä ryhmissä, mutta niille on olemassayksinkertaisempia ja siihen käyttöön parempia ja tehokkaampia ratkaisuja. Arkki-tehtuuri perustuu päästä-päähän-malliin, eli se ei ota kantaa reititykseen. Tosin vää-ränlainen reititys saattaa johtaa palveluiden estoon (DoS) sovelluskerroksella, jokatoteuttaa tämän arkkitehtuurin. Reititys ei kuitenkaan vaikuta tunnistamiseen, tie-don salassapitoon tai pakettien hallinnointiin, mitä tämä arkkitehtuuri pääasiassakäsittelee.

T. Hardjono ja B. Weis kuvaavat dokumentissa [4] kolme aluetta, joiden on to-teuduttava, jotta voidaan taata turvallinen yhteydenpito ryhmälähetyksissä:

Ryhmälle lähetettävä data pitää käsitellä siten, että se salataan ryhmäavaimellapääsynvalvontaa ja mahdollisesti luottamuksellisuuden osoitusta varten, sekä onluotava aitouden osoitus, jotta tiedon lähde ja koskemattomuus voidaan taata. Tosinkoskemattomuutta ei voida taata, jos ryhmän jäsenillä on oikeus muokata tietoa jalähettää sitä eteenpäin. Tällöin siis vain lähde voidaan todentaa.

Toisena alueena on tiedon suojaukseen käytettyjen turvallisuuskäytäntöjen tar-vittava lähetys ja päivitys. Käyttäjän tunnistusta ja todentamista voidaan pitää esi-merkkinä eräästä tällaista toimenpidettä vaativasta tapahtumasta. Tämä alue sisäl-tää siis joukon turvallisuuskäytäntöjä (GSA5), jotka yhdessä määrittelevät sen, kuin-ka ryhmän kommunikointi tapahtuu turvatusti. Turvallisuuskäytännöt (SA6) voi-daan jakaa kolmeen eri ryhmään, joista jokainen sisältää joukon politiikoita (lähde-ja kohdeportit, avaimen eliniät, jne.) ja salausavaimia (todennus-, salaus- ja allekir-joitusavaimia). Turvallisuuskäytännöistä kerrotaan tarkemmin seuraavassa kappa-leessa avaintenhallinnan yhteydessä.

Viimeisenä alueena on turvallisuuspolitiikka, joka pitää sisällään ryhmälähetyk-sen turvallisuusmäärityksiä, joita päivitetään ryhmää hallitseville elimille.

Dokumentti tekee myös ehdotuksen fyysisen tason arkkitehtuuriksi (Kuva 1),joka käsittelee, hallinnoi, sekä luo edellä mainittuja palveluita. Fyysinen arkkiteh-tuuri muodostuu kaiken kaikkiaan turvallisuuspolitiikkapalvelimesta, ryhmän hal-linta/avain palvelimesta ja varsinaisista tiedon vastaanottajista ja lähettäjistä.

Arkkitehtuurillisesti ylimpänä on turvallisuuspolitiikkapalvelin, joka luo ja hal-litsee turvallisuuspolitiikoita. Palvelin keskustelee ryhmän hallinta/avain palveli-men (GCKS7) kanssa päivittääkseen sille oikean politiikan, eli oikeat avaimet, ja niin

5Group Security Association6Security Association7Group Controller/Key Server

3

Kuva 1: Ryhmälähetysten fyysinen turvallisuusarkkitehtuuri

edelleen.Seuraava kerros sisältää siis ryhmän hallinta/avain palvelimen, jonka vastuulla

on salausavainten hallinta, käyttäjätunnistus ja valtuutustarkastukset niin laite kuinkäyttäjätasollakin.

Alimmalla kerroksella ovat lähettäjät/vastaanottajat, jotka ovat ryhmälähetys-ryhmän jäseniä. Lähettäjien/vastaanottajien vastuualueena on luonnollisesti lähet-tää tai vastaanottaa dataa. Lähettäjän/vastaanottajan on myös keskusteltava ryh-män hallinta/avain-palvelimen kanssa suorittaakseen avaintenhallintaoperaatiot,jotta esimerkiksi datan salausavaimet ovat ajan tasalla.

Monesti tällaista fyysisen tason rakennelmaa ei pystytä luomaan pelkästään yh-teen fyysiseen paikkaan, vaan täytyy luoda useita tällaisen arkkitehtuurin (Kuva 2)toteuttavia kokonaisuuksia. Tällainen tarve on esimerkiksi mannerten välisissä yh-teyksissä, jolloin siis tarvitaan usean ryhmän yhteistyötä. Tällaisessa tapauksessamolempien päiden turvallisuuspolitiikkapalvelimet ja GCKS:t keskustelevat keske-nään taatakseen yhtenäiset linjaukset.

4

Kuva 2: Fyysisten turvallisuusarkkitehtuurien yhteistyö

5 Ryhmälähetysten avaintenhallinta-arkkitehtuuri

Ryhmälähetysten avaintenhallinta-arkkitehtuuri on edellä esiteltyä turvallisuusark-kitehtuuria hieman abstraktimpi käsite. Käytännössä tämä arkkitehtuuri määritte-lee ryhmän turvallisuuskäytännön GSA:n, joka sisältää turvallisuusarkkitehtuurissaesille tulleet kolme turvallisuuskäytäntöä (Kuva 3): DATA SA:n, (valinnaisen) avai-menuudistus (engl. Rekey) SA:n ja rekisteröinti SA:n.

Hieman tarkemmin sanottuna rekisteröinti eli REG SA:ta käytetään kirjautues-sa ryhmään, tästä syystä sitä voidaan pitää kahden muun ryhmän turvaavana pro-seduurina. REKEY on turvallisuuskäytäntö, jota käytetään ryhmän hallinta/avain-palvelimen (GCKS) päivittäessä turvallisuuskäytäntöjä kaikille ryhmän jäsenille. RE-KEY:tä voidaan käyttää myös tilanteessa, jossa tulee äkillinen tarve poistaa jäse-nen/jäsenien oikeudet. Viimeinen käytännöistä on DATA-niminen käytäntö, jotakäytetään nimensä mukaisesti datan turvaamiseen lähettäjien ja vastaanottajien vä-lillä.

Nämä turvallisuuskäytännöt sisältävän avaintenhallintaprotokollan on M. Baugh-nerin, R. Canettin, L. Dondetin ja F. Lindholmin luoman RFC-dokumentin [6] mu-kaan kyettävä toteuttamaan seuraavat kohdat:

5

Kuva 3: Turvallisuuskäytäntöjen käyttö

• Ryhmän jäsenet saavat turvallisuuskäytännöt, jotka sisältävät salausavaimet,todennusavaimet ja salauspolitiikan.

• Edellä mainittujen lisäksi ryhmän hallinnoijan on voitava määritellä ja pannatoimeen erinäisiä politiikoita, kuten esimerkiksi datan salauspolitiikka.

• Avaimilla on ennalta määrätty elinikä ja niitä voidaan tietyin aikavälein päi-vittää.

• Avainmateriaali pitää toimittaa jäsenille turvatusti siten, että ne ovat salaisia,koskemattomuus on taattu ja todistettavasti saatu valtuutetulta lähteeltä.

• Avaintenhallintaprotokollan pitää olla turvallinen muun muassa palvelunes-tohyökkäyksiä vastaan (DoS).

• Protokollan pitää sisältää ryhmän jäsenien lisäyksen ja poiston.

• Protokollan pitää tukea skaalautuvaa ryhmän avaimen uudistusoperaatiota(engl. rekey operation) ilman, että tarvitaan jäsenien ja ryhmän ohjaimen välis-tä kommunikaatiota. Tämä estää GCKS:n ylikuormittumisen, jos kyseessä isoryhmä.

6

• Protokollan pitää olla yhteensopiva datan turvallisuussovelluksen (esimerkik-si IPsec) infrastruktuurin ja suoritusvaatimusten kanssa.

• Avaintenhallintaprotokollan pitää tarjota puitteet valtuutusinfrastruktuurin,todennussysteemin ja muutoksien uudistamiselle tai korvaamiselle.

• Protokollan pitää kyetä suojautumaan luvattomilta yrityksiltä saada salaistatietoa käsiinsä.

• Protokollan pitää taata mekanismi toipumiseen tilanteesta, jossa osa tai kaikkiavainmateriaalista on paljastunut.

• Avaintenhallintaprotokollan pitää tarvittaessa voida ottaa kantaa verkonkäy-tännön ratkaisuihin, kuten esimerkiksi NAT:in (engl Network Address Transla-tor) tuomiin vivahteisiin.

6 Tulkinta-alue GDOI

ISAKMPin 8 pohjalta kehitetty GDOI 9 kuvaa ryhmäavainten käyttöä turvatussa yh-teydenpidossa ryhmän jäsenen ja ohjaimen välillä. GDOI hallinnoi ryhmän turvalli-suuskäytäntöjä (SA10), joita käyttävät IPSEC ja mahdollisesti muut datansalauspro-tokollat, jotka ovat IP- tai sovelluskerroksilla. SA:t suojaavat yhtä tai useampaa sa-lausavaimen avainta, salatun liikenteen avainta tai ryhmän jäsenten kesken jaettuadataa.

ISAKMP määrittelemät kaksi eri vaihetta osapuolien välille pätevät myös GDOI:ssa,tosin sillä poikkeuksella, että GDOI ehdottaa toiseen vaiheeseen uusia hyötykuor-mia (engl. payloads) ja vaihtoja (engl. exchanges).

Ensimmäisellä vaiheella tarkoitetaan SA:ta, joka takaa vertaistunnistuksen, luot-tamuksellisuuden ja viestin eheyden. GDOI:n on oltava suojattu tämän vaiheen mu-kaisella SA:lla.

Toiseen vaiheeseen GDOI tulevia lisäyksiä ISAMKMP standardiin verraten onesitetty asiaa käsittelevässä RFC-dokumentissa[3]. Uudet hyötykuormat ovat doku-mentista löytyvän määritelmän mukaan seuraavanlaiset:

• GDOI turvallisuuskäytäntö (SA),

• Turvallisuuskäytännön avaimen salausavain (KEK11)8Internet Security Association and Key Management Protocol9Group Domain of Interpretation

10Security Association11Key Encryption Key

7

• Turvallisuuskäytännön liikenteen salausavain (TEK12)

• Avaimen lataustaulukko (KD13)

• Järjestysnumero (SEQ14)

• Todiste omistuksesta (POP15)

Samaisessa dokumentissa [3] M. Baugher, B. Weis, T. Hardjono ja H. Harney ku-vaavat myös seuraavat uudet vaihdot:

Ensimmäisessä uudessa vaihdossa luodaan uusi avain (engl. Rekey) ja datan sa-lausprotokollan turvallisuuskäytännöt. Tässä uudelleen määritellyssä vaiheessa la-dataan ryhmän ohjaimelta avaimet ryhmän rekeytä ja/tai datan salausprotokollanturvallisuuskäytäntöjä varten. Tämä lataus tapahtuu aina ryhmän jäsenen toimes-ta. Rekey SA sisältää ryhmälle yhteisen avaimen salausavaimen (KEKin). Data SAsisältää taas datan salausavaimen (TEK:n), jota käytetään datan salausprotokollassasalaamaan tai purkamaan dataliikennettä. Turvallisuuskäytännöt KEK:lle ja TEK:llesisältävät autentikointiavaimet, salausavaimet, kryptauspolitiikan ja tarvittavat att-ribuutit turvallisen yhteydenpidon hallinnointiin. Ryhmän jäsenen tunnistaminenvaltuutetuksi jäseneksi ryhmäavaimen hakemisessa voidaan hoitaa joko käyttämäl-lä aiemmin esiteltyä ensimmäisen vaihetta jäsenen tunnistamiseen tai lisäämälläryhmäavaimen hakukutsuun identiteetti. Identiteetin hyväksyminen tapahtuu si-ten, että ryhmän hallitsija on hyväksynyt sertifikaatin, joka määrittelee ryhmään oi-keutetut identiteetit.

Toinen uusi vaihto kuvaa tietyin väliajoin lähetettävän datagrammin, joka lähe-tetään ryhmän ohjaimelta jäsenille, jotta heille joko luodaan tai päivitetään rekeyntai datan turvallisuuskäytännöt. Yleisin käyttö tälle lähetykselle onkin juuri datanturvallisuuskäytäntöjen luominen datansalausprotokollia varten.

Vaikka M. Baugher, B. Weis, T. Hardjono ja H. Harney käsittelevätkin RFC-dokumentissaanvain IPsecin ESP:n16 käyttöä datansalausprotokollana, taataan siinä myös, että GDOI:tavoidaan tarvittaessa soveltaa myös muihin datansalausprotokolliin. Näitä datansa-lausprotokollia voidaan käyttää tulevaisuudessa esimerkiksi salaamaan reaaliaikai-sen datan kuljetusprotokollaa.

12Traffic Encryption Key13Key Download Array14Sequence Number15Proof of Possession16Encapsulated Security Protocol

8

GDOI on siis ryhmän turvallisuuskäytäntöjen hallintaprotokolla: kaikki GDOIviestit joko luovat, ylläpitävät tai tuhoavat ryhmän turvallisuuskäytäntöjä. Käytän-nöt suojelevat yhtä tai useampaa avaimen salausavainta, liikenteen salausavaintatai jaettua dataa käytettäessä ryhmälähetystä tai ryhmän salattuja sovelluksia, joitavoivat olla esimerkiksi videon yleislähetys tai tiedonsiirto ryhmälähetyksenä.

7 Multimedian salausavaimet

Multimedian salausavaimet (MIKEY17) on tarkoitettu reaaliaikaisia sovelluksia var-ten niin peer-to-peer-yhteyksiä kuin ryhmälähetyksiäkin varten. Avaintenhallintapystytään MIKEY:n avulla toteuttamaan heterogeenisissä verkoissa, eli mukana voiolla niin langallisia kuin langattomiakin koneita.

MIKEY:n ymmärtämisen selventämiseksi käydään läpi muutamat yhteystyypit(Kuva 4), sekä kuinka niissä hoidetaan turvallisuusasetukset.

Peer-to-peer-yhteyksillä (P2P) tarkoitetaan normaalisti kahden osapuolen välistäyhteydenpitoa, jossa lähtevän tiedon turvallisuusasetukset on hoidettu joko yhtei-sellä sopimuksella tai sitten kummatkin osapuolet hoitavat itse omat asetuksensa.

Yhdeltä-monelle-yhteydessä, eli joukkolähetyksessä, itse lähettäjä on vastuussaturvallisuusasetuksista.

Monelta-monelle-yhteydessä, jossa ei ole erillistä kontrollointiyksikköä, jokainenryhmän jäsen voi määritellä omat turvallisuusasetuksensa lähtevälle tiedolle. Tästämallista on olemassa kaksi eri vaihtoehtoa: ryhmän alullepanija hallinnoi, kuka voiliittyä ryhmään ja kuka ei. Toinen vaihtoehto on, että myös ryhmän jäsenille voidaanantaa mahdollisuus lisätä uusia jäseniä.

Viimeisenä käsiteltävänä yhteystyyppinä on monelta-monelle-yhteys keskitetyl-lä kontrollointiyksiköllä, jossa kontrollointiyksikkö hoitaa turvallisuusasetukset.

MIKEY:tä suunniteltaessa pääpaino on ollut kolmessa ensimmäiseksi mainitussayhteydenpitotyypissä, eli P2P-, yhdeltä-monelle- sekä monelta-monelle-yhteyksissäilman kontrollointiyksikköä.

MIKEY:n edeltäjinä toimineet ajatusmallit pystyivät toimimaan hyvin täsmälä-hetyksissä sekä myös ryhmälähetyksissä, mutta vasteaika oli yleensä ongelmakoh-ta niitä käytettäessä. Tästä syystä päätettiin kehittää ajatusmalli, jossa vasteaika oli-si tarpeeksi hyvä toimimaan reaaliaikaisen datan käsittelyssä. Tämä tarpeeksi hy-vällä vasteajalla toimiva MIKEY toteuttaa ’MIKEY: Multimedia Internet KEYing’ -artikkelin[5] mukaan seuraavat piirteet:

17Multimedia Internet KEYing

9

Kuva 4: Yhteystyypit

• Päästä-päähän turvallisuus, eli ainoastaan osallisilla on pääsy luotuihin avai-miin.

• Yksinkertaisuus, eli ei sisällä tarpeettomia ominaisuuksia ja on toiminnaltaanhelposti ymmärrettävä.

• Tehokkuus, eli esimerkiksi MIKEY pyrkii vähäiseen kaistankulutukseen, sekäkäytön vaatimaan laskentatyöhön.

• Tunnelointi, eli mahdollista tunneloida/integroida MIKEY istunnon perusta-viin protokolliin, esimerkiksi RTSP18.

• Riippumattomuus kaikista alla olevan kuljettimen turvallisuustoimista.

• MIKEY tuottaa DATA SA:n turvallisuusprotokollan käyttöä varten.

MIKEY:n käytännön toteutuksen ymmärtämistä varten on tarpeen käydä läpimuutamia keskeisiä termejä:

18Real Time Secure Protocol

10

• Crypto session (CS), eli salattu istunto tarkoittaa yksi tai kaksisuuntaista yh-den tieturvaprotokollan avulla suojattua tietovirtaa, joka voidaan mieltää myösosana DATA turvallisuuskäytäntöä.

• Crypto session bundle (CSB), eli joukko salattuja istuntoja, joka tarkoittaa käy-tännössä joukkoa CS:iä, joilla on yhteinen TGK (selitetään alla) ja turvallisuus-parametrit.

• Transmission encryption key (TEK), eli liikenteen salausavain tarkoittaa tur-vallisuusprotokollan käyttämää avainta salatun istunnon suojaamiseen.

• TEK generation key (TGK), eli TEK:in luomisavain tarkoittaa bittijonoa, jokaon sovittu kahden tai useamman osapuolen kanssa, joilla on yhteinen CSB.TGK:stä voidaan luoda liikenteen salaus-avain (TEK) ilman lisäkommunikaa-tiota.

• TGK REKEY, eli luomisavaimen uudistaminen on uudelleen neuvottelu/päi-vitysprosessi TGK:lle.

• Alullepanijalla (engl. initiator) tarkoitetaan avaintenhallintaprotokollan alulle-panijaa, eikä siis tässä tapauksessa yhteyden alullepanijaa.

• Vastaaja (engl. responder) on avaintenhallintaprotokollan vastaaja.

MIKEY:n käytännön toteutus etenee siten, että aluksi sovitaan joukko turvalli-suus parametreja, sekä sovitaan TGK:t CSB:tä varten. Tämän jälkeen TGK:sta luo-daan TEK:t jokaiselle CS:lle. TEK ja turvallisuusprotokollan parametrit muodosta-vat yhdessä DATA SA:n, jota käytetään syötteenä turvallisuusprotokollalle.

7.1 ECC Algoritmit MIKEY:lle

EEC19-algoritmit tarjoavat MIKEY:hin laajennuksia todennuksen, salauksen ja di-gitaalisen allekirjoituksen saralta. MIKEY:n määrittelevässä RFC-dokumentissa[5]kuvataan kolme avaintenvaihtotapaa: ennalta jaettu avain (MIKEY-PSA), julkinenavain (MIKEY-RSA) ja valinnainen tuki diffie-hellmanille (MIKEY-DHSIGN). A. Mil-nen, M. Blaserin, D. Brownin ja L. Dondetin luomassa Internet-draftissa[14] on esi-tetty uusia avainten vaihtotapoja, joista esimerkiksi elliptic curve diffie-hellmannia(ECDH) voidaan käyttää ilman muutoksia MIKEY:n diffie-hellman metodina. Myös

19Elliptic-curve cryptography

11

muita yhdenaikaisia avaintenvaihto ja digitaalisen allekirjoituksen elliptic curve pro-tokollia voidaan käyttää MIKEY:ssa tuomaan merkittäviä parannuksia suoritusky-kyyn ja turvallisuuteen.

Tässä tutkielmassa ei mennä yksityiskohtiin siitä, kuinka edellä mainitut turval-lisuuden ja suorituskyvyn parantamiset voidaan toteuttaa, mutta yleisellä tasollavoidaan todeta, että esimerkiksi EC-allekirjoituksia voidaan käyttää sertifioimaanMIKEY:ssa käytettyjen julkisten avainten allekirjoituksia ja allekirjoitusoperaatioita,joka mahdollistaa pienempien ja tehokkaampien allekirjoituksien ja sertifikaattienkäytön.

7.2 HMAC-todennettu diffie-hellman MIKEY:lle

Tämä sovelluskerroksella toimiva MIKEY:n muunnelma kuvaa kevyen pisteestä-pisteeseen avaintenhallintaprotokollan. HMAC-todennettu diffie-hellman MIKEY:lletähtää siihen, että se pystyy tuottamaan täydellisen turvallisuuden avainten sopimi-sen osana ilman julkisen avaimen infrastruktuuria, eli PKI:ta20. PKI:n poistaminentästä ketjusta nopeuttaa toimintaa, sillä PKI:n käyttö saattaa pahimmissa tapauksis-sa vaatia huomattavaakin laskentatehoa.

Aihetta käsittelevässä dokumentissa[9] esitellään ratkaisu PKI:n poistamiseen,jonka ideana on käyttää diffie-hellman avaintensopimismenetelmää, jossa ei kui-tenkaan käytetä MIKEY:n normaalin diffie-hellman avaintensopimismenetelmän ta-paan digitaalista allekirjoitusta. Digitaalisen allekirjoituksen sijaan vaihdetun avain-materiaalin todennukseen käytetään avaintiivistettä (HMAC), joka perustuu ennal-ta jaettuihin avaimiin.

7.3 Lisämoodi MIKEY:n avainten jakamiseen: MIKEY-RSA-R

MIKEY-RSA käänteismoodi (MIKEY-RSA-R) on sellaisia julkisen avaimen jakami-songelmatilanteita varten, joissa vastaanottajan julkista avainta ei tiedetä, tai joissavastaanottajan identiteetti ei ole selvillä. D. Ignjaticin, L. Dondetin, F. Audetin ja P.Linin julkaisemassa dokumentissa[15] esitellyn moodin tarkoitus on myös tukea ti-lanteita, joissa on tarkoituksenmukaista toimittaa useampi kuin yksi TGK, sillä il-man tätä moodia se pitää hoitaa luomalla useita MIKEY istuntoja, joka ei ole kovintehokasta.

20Public Key Infrastructure

12

7.4 Yleisen hyötykuorman laajennus MIKEY:ssa

Multicast Broadcast/Multicast Service (MBMS), eli ryhmälähetyspalvelut vaativat,että avaimia päivitetään usein, sillä ei ole mielekästä, että ryhmän ulkopuolinen sai-si avaimet käsiinsä ja täten pääsisi käsiksi tietoon ilman oikeuksia tai mahdollistamaksua. Toteuttaakseen tämän MBMS käyttää kolmikerroksista avaintenhallintaajakaakseen ryhmäavaimia asiakkaille ja päivittääkseen avaintietoja. Kerrokset ovataihetta käsittelevän ’Key ID Information Type for the General Extension Payload inMIKEY’ -dokumentin[13] mukaan seuraavanlaiset:

• MBMS käyttäjäavain (MUK21) on ryhmälähetyspalvelimen ja jokaisen asiak-kaan välillä käytettävä pisteestä-pisteeseen avain.

• MBMS palveluavain (MSK22) on ryhmälähetyspalvelimen ja kaikkien asiak-kaiden välillä toimiva ryhmäavain.

• MBMS liikenneavain (MTK23) toimii ryhmälähetyspalvelimen ja asiakkaidenvälillä ryhmäliikenneavaimena. Liikenneavaimet ovat tämän kerrosmallin avai-mista ne, joita päivitetään säännöllisesti/usein, jotta taataan palveluiden jat-kuva turvallisuus.

Avaimien käyttö menee siten, että MUK:ia käytetään turvaamaan ensimmäinentaso, jossa toimitetaan toisen tason MSK-avain. MSK-avainta käytetään taas MTK-avaimen toimitukseen, joka on siis todellinen suojausavain medialiikenteelle.

Jotta yllä mainittu avaintenjakaminen voidaan toteuttaa, pitää MIKEY-viestissäolla mukana tieto avaimen tyypistä ja identiteetistä. Tieto kuljetetaan MIKEY:n ylei-sen hyötykuorman laajennuksessa.

8 Ryhmäavainten jakoprotokolla

Yleensä ottaen turvallisuuskapselointiprotokollat kuten IPsec ja SRTP24 takaavatluotettavuuden, viestin eheyden, toisintosuojan ja joissain tapauksissa myös pää-synvalvonnan ja datan lähteen todennuksen. Edellä mainitut turvallisuuspalvelutvoidaan hoitaa manuaalisesti, mutta jotta päästäisiin tehokkaaseen tulokseen, onne suotavaa hoitaa automatisoidusti. Pisteestä-pisteeseen-mallia varten suunnitel-lut turvallisuuskäytännöt, kuten IKE ja sen seuraaja IKEv2, ovat laajasti käytettyjä

21MBMS User Key22MBMS Service Key23MBMS Traffic Key24Secure Real Time Protocol

13

IPsec:in turvallisuuskäytäntöjä, jotka hoitavat edellä mainittuja turvallisuuspalve-luita. Koska IKE ja sen seuraaja ovat olleet jo pitkän aikaa kehityksen ja testauksenalla, on niiden pohjalta kehitetty ryhmälähetystilanteisiin vastaava turvallisuuskäy-täntö Group Key Distribution Protocol (GKDP), eli ryhmäavaintenjakoprotokolla.GKDP:n tehtäviin ryhmälähetystilanteissa kuuluvat jäsenten rekisteröinti ja avain-ten uudistus.

’GKDP: Group Key Distribution Protocol’ -artikkelissa[17] esitelty ryhmäavain-tenjakoprotokolla perustuu siis laajalti jo olemassa olevaan IKE:n koodipohjaan. Se,että käytetään olemassa olevaa koodipohjaa estää sen, että ei kompastuta samoihinvirheisiin, joita on mahdollisesti tehty IKE:n suunnittelussa. Edellä mainitusta syys-tä on siis kehitetty jälleen uusi ryhmäavaintenjakoprotokolla, vaikka myös muitakyseisen tehtävän toteuttavia ratkaisuja on jo olemassa. Vaikka GKDP on kehitettyIKEv2:n pohjalta ja siinä on osittain käytetty myös samaa koodipohjaa, eivät ne olemillään tapaa toisistaan riippuvaisia ja siksi GKDP pystyy toimimaan itsenäisesti.

GKDP on avainten latausprotokolla, ei avainten neuvotteluprotokolla, kuten osamuista ryhmälähetystilanteisiin luoduista ratkaisuista. Tämä tarjoaakin monia mie-lenkiintoisia aspekteja; se vaatii vähemmän viestejä toimiakseen ja näin ollen no-peuttaa sen toimintaa.

9 Turvallisuuskäytäntöjen avaintenhallintaprotokolla

Ryhmälähetyksien turvallisuusarkkitehtuurissa[6] määriteltyjen vaatimusten poh-jalta ovat H. Harley, U. Meth, A. Colegrove ja G. Gross kehittäneet Group SecureAssociation Key Management Protocol (GSAKMP)[8], eli turvallisuuskäytäntöjenavaintenhallintaprotokollan. GSAKMP on siis turvallisuuskehys verkossa toimiviensalattujen ryhmien luontiin ja hallinnointiin.

Se tarjoaa mekanismit ryhmäpolitiikoiden ja avaimen levittämiseen, käyttäjientodentamiseen, sekä säännöt siitä kuinka suoritetaan pääsynvalvontapäätökset kunollaan perustamassa ryhmää tai palauttamassa sitä. GSAKMP tarjoaa myös meka-nismit siihen, kuinka voidaan palautua, jos ryhmän jäsenten tiedot ovat vaarantu-neet, kuinka jaetaan ryhmän turvallisuusfunktioita eteenpäin ja kuinka ryhmä voi-daan tuhota. Protokolla myös luo ja hallitsee ryhmäavaimia.

Protokolla jakaa aiemmin esitellyn ryhmälähetyksien turvallisuusarkkitehtuu-rin tavoin ryhmän hallinnan kolmeen portaaseen: 1) Ryhmän omistaja, 2) Ryhmänhallinta/ avain-palvelin (GCKS) ja 3) Ryhmän jäsen.

14

Ryhmän omistaja (GO25) on vastuussa turvallisuuspolitiikoiden luonnista. GO:nluotua turvallisuuspolitiikan sen pitää sisällyttää se niin sanottuun ryhmäpolitiik-kapolettiin (PT26). Poletti sisältää muun muassa seuraavat asiat:

• GSAKMP protokollan version,

• avainten luontitavan,

• avainten levityspolitiikan,

• pääsynvalvontapolitiikan,

• ryhmän valtuutuspolitiikan,

• politiikan siitä, kuinka toivutaan tiedon vaarantumisesta, sekä

• tiedon suojausmekanismit.

GCKS on vastuussa avainten luonnista ja hallinasta, joka pitää sisällään myösavainten päivityksen. GCKS on myös vastuussa turvallisuuspolitiikoiden täytän-töönpanosta siinä määrin, että se myöntää oikeuksia potentiaalisille ryhmän jäse-nille, jotka hyväksyvät/toteuttavat ryhmäpolitiikkapoletin ehdot.

GCKS:n alla ryhmän jäsen voi tarpeen vaatiessa toimia myös alisteisena GCKS:nä.Tällaisen alaisen tehtäviin kuuluu muuten samat tehtävät kuin varsinaisella GCKS:llä,paitsi ryhmäliikenteen suojausavaimen (GTPK27) luonti. GTPK:ta ei saa luoda sentakia, koska oletetaan, että koko ryhmä toimii yhden GTPK:n varassa ja alkupe-räinen GCKS luo sen. Alaisia luodaan esimerkiksi sellaisissa tapauksissa, joissa ontarvetta laajentaa ryhmää.

Ryhmän jäsenellä on periaatteessa kaksi tehtävää: pidettävä huolta, että kaikkiturvallisuuteen liittyvät teot ovat valtuutettuja ja lisäksi ryhmäavaimia on käytettä-vä oikein, eli jäsenet eivät saa esimerkiksi luovuttaa avaimia ei valtuutettujen hen-kilöiden käsiin. Näiden tehtävien täyttyminen tukee järjestelmätason turvallisuus-politiikkaa siten, että ryhmän jäseniä voidaan pitää luotettuina ja täten mahdollistaaluotetun yhteydenpidon ja turvallisuuspalveluiden hallinnan.

Ryhmän luonti tapahtuu aihetta käsittelevän Internet-draftin[8] mukaan siten,että aluksi lähetetään PT potentiaaliselle GCKS:lle. GCKS varmistaa ryhmän omis-tajan signatuurin PT:ssä, jotta saadaan varmuus, että se tulee luotetusta lähteestä.

25Group Owner26Policy Token27Group Traffic Protection Key

15

Seuraavaksi GCKS varmistaa PT:n sisältämistä säännöistä, että sen on laillista tul-la GCKS:ksi. Jos edellä mainitut vaiheet toteutuvat, tulee potentiaalisesta GCKS:stäGCKS. Tämän jälkeen GCKS luo tarvittavat avaimet ja mahdollisesti ilmoittaa, ettäse voi jakaa näitä ryhmäavaimia. Tämän jälkeen GCKS jääkin odottamaan potenti-aalisten ryhmän jäsenten ryhmään liittymispyyntöjä.

Saadessaan liittymispyynnön, GCKS varmistaa, että potentiaalinen ryhmän jä-sen on oikeutettu saamaan haltuunsa ryhmän avaimia. Tämän jälkeen GCKS var-mistaa, että pyynnön signatuuri on todella lähetetty ilmoitetusta lähteestä. Jos tämäonnistuu, lähettää GCKS avaimen latausviestin.

Potentiaalisen jäsenen saadessa avaimen latausviestin, täytyy jäsenen aluksi vah-vistaa sen signatuuri. Tämän jälkeen jäsen etsii viestistä PT:n ja varmistaa, että ryh-män omistaja on todella luonut ja allekirjoittanut sen. Kun tämä varmistus on tehty,jäsen varmistaa, että GCKS:llä on oikeus jakaa avaimia tälle ryhmälle. Jos GCKS:lläon oikeus jakaa avaimia, niin seuraavaksi varmistetaan, että ryhmän mekanismitdatan suojaamiselle (jos ryhmän jäsen on datalähde) ovat saatavilla ja hyväksyttä-vät tähän tarkoitukseen. Tämän jälkeen potentiaalinen jäsen hyväksyy jäsenyyden.Jäsen voi vielä tarkistaa, onko sillä oikeutta toimia alisteisena GCKS:nä. Jos tällainenoikeus on, niin sitten ryhmän jäsen vaihtaa tilansa alisteiseksi GCKS:ksi ja toimii senmukaan.

Ryhmän jäsenen poistaminen ryhmästä voidaan hoitaa kolmella eri tavalla:Ensimmäinen tapa on ryhmän jäsenen häätäminen. Tällöin toimitaan siten, että

poistetaan käytöstä kyseisen jäsenen avaimet lähettämällä muille jäsenille avaimenpäivitykset. Jos halutaan, että kyseinen jäsen ei saa jatkossakaan kuulua ryhmäänpitää hänet lisätä kiellettyjen jäsenien pääsynvalvontalistaan ja täten myös päivittäätieto PT:hen.

Ryhmän jäsen voi tehdä myös niin sanotun vapaaehtoisen poistumisen ilman il-moitusta, jos ryhmän jäsenyys ei aiheuta kustannuksia tai velvollisuuksia poistuval-le jäsenelle. Tällöin riittää, että jäsen voi halutessaan poistaa itsellään olevat avaimetja lopettaa ryhmässä toimimisen.

Jos taas jäsenyys aiheuttaa kustannuksia ja/tai velvollisuuksia, niin tällöin pitäi-si ehdottomasti suorittaa poistuminen ryhmästä siten, että siitä ilmoitetaan asian-omaisille tahoille. Oikeaoppisella poistumisella tarkoitetaan sellaista tapahtumienketjua, jossa aluksi lähetetään GCKS:lle pyyntö poistua ryhmästä, jonka jälkeen GCKSlähettää vastineen tähän, joka tulee vielä kuitataan poistuvan jäsenen toimesta.

16

10 Ryhmäpolitiikkapoletti

GSAKMP:n yhteydessä mainittu ryhmäpolitiikkapoletti on rakenne, joka määritte-lee turvallisuuspolitiikan ja tarvittavat parametrit ryhmälle. Politiikkapoletti on ryh-män omistajan luoma ja allekirjoittama kokoelma ryhmän politiikoita, jota ryhmänhallitsija/avainpalvelin käyttää esimerkiksi potentiaalisen ryhmän jäsenen ryhmäänliittämiseen.

A. Colegroven ja H. Harneyn kirjoittamassa ’Group Policy Token v1’ -dokumentissa[12]kuvatun ryhmäpolitiikkapoletin rakenne on seuraavanlainen:

Ensimmäisenä on poletin infokenttä, joka pitää sisällään ryhmän yksikäsitteises-ti identifioivan nimen ja valinnaisen järjestysnumeron. Jos järjestysnumero on käy-tössä, ryhmän entiteettien on hyväksyttävä vain sellaisia politiikkapoletteja, joissakyseinen järjestysnumero on isompi kuin edellisessä.

Seuraavana tulee rekisteröintiosa, jossa kuvataan hyväksyttävät rekisteröinti- japoistumispolitiikat. Jos tämä osa on tyhjä, se tarkoittaa sitä, että ryhmä ei tue rekis-teröintiä eikä siitä poistumista. Tämä osa voi sisältää myös useita eri tapoja rekiste-röityä/poistua, jolloin jäsen voi valita niistä itselleen parhaiten sopivan.

Avaimen uudistusosa (REKEY) seuraa rekisteröinti osaa ja se kuvaa avaimenuu-distusprotokollat, joita käytetään ryhmänhallinnassa.

Viimeisenä oleva dataosa kuvaa sovellukset, joita käytetään ryhmän jäsenienvälisessä kommunikaatiossa. Useampia sovelluksia kuvattaessa järjestys, jossa neovat, kuvaa järjestyksen, jossa data on kapseloitu.

Kun edellä kuvatun rakenteen omaava politiikkapoletti saapuu vastaanottajalle,on siitä tarkistettava seuraavat seikat:

• Ryhmän omistaja on se keneksi se oletetaankin.

• Allekirjoitusaika on uudempi kuin aiemmassa politiikkapoletissa, mikäli alle-kirjoitusaika on käytössä.

• Allekirjoituksen käsittely onnistuu.

• Määritetyt turvallisuus ja kommunikointi mekanismit noudattavat vastaanot-tajan paikallista politiikkaa.

17

11 RSA/SHA-1 allekirjoituksien käyttö ESP:n ja AH:n sisällä

IP-protokollan sisältämiä ESP:tä28 ja AH:ta29 voidaan molempia käyttää suojaamaansekä täsmälähetys- että ryhmälähetystyyppistä liikennettä. Todennusotsikko (AH)tarjoaa todennuksen ja eheyden lisäksi myös kiistämättömyyden. Mikäli käytetäänepäsymmetristä salakirjoitusmenetelmää, tiedon salaukseen tarvittavaa ESP:tä voi-daan käyttää salakirjoittamaan koko paketti ja tällöin pakettiin liitetään uusi osoi-tekenttä (tunnelointi). ESP:tä voidaan käyttää myös salakirjoittamaan vain paketindataosa.

Täsmälähetyksissä riittää HMAC-tiivisteen käyttö, sillä vain kahdella osapuolel-la on pääsy käsiksi avaimiin, sekä lähettäjän todennus on yksinkertaisempaa. Kui-tenkin ryhmälähetyksessä tilanne on toinen, sillä silloin jokainen ryhmän jäsen jakaatämän yhden HMAC-avaimen, jolloin datan lähettäjän todennus ei ole saavutetta-vissa. Tällöin voidaan ottaa käyttöön Brian Weisin ’The Use of RSA/SHA-1 Signa-tures within ESP and AH’ -dokumentissa[10] esittelemä menetelmä RSA:n käytöstäluomaan digitaalinen allekirjoitus ESP:tä ja AH:ta käytettäessä, jolloin lähettäjän to-dennus on jälleen mahdollista.

RSA:ssa käytettyjen arvojen valinta pitää tehdä harkitusti, sillä jos valitaan liianpieniä arvoja, se aiheuttaa sen, että potentiaalinen hyökkääjä pystyy rekonstruoi-maan yksityisen avaimen ja käyttämään sitä omiin tarkoituksiinsa. On siis syytävalita tarpeeksi isoja arvoja, jotta niiden rekonstruoiminen vaatisi niin mittavan las-kentatehon, että ei ole enää mielekästä yrittää tehdä niin.

RSA:n huono puoli kuitenkin piilee siinä, että se on hyvin laskentatehollisestikallis ja aikaa vievä prosessi verrattuna esimerkiksi HMAC algoritmeihin.

12 Tehohäviötön todentaminen

A. Perrigin, D. Songin, R. Canettin, J. D. Tygarin ja B. Briscoen ’Timed EfficientStream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Trans-form Introduction’ -dokumentissa[7] esittelemä tehohäviötön todentaminen antaavastaanottajille mahdollisuuden varmistaa ryhmälähetyksessä sekä yleislähetykses-sä jokaisen paketin koskemattomuuden sekä todentaa paketin lähteen. Se, että voi-daan varmistaa koskemattomuus ja lähteen aitous takaa sen, että väärinkäyttöjenmahdollisuus pienenee.

Lähettäjä voidaan varmistaa kahdella eri tavalla: asymmetrisellä ja symmetrisel-

28Encapsulated Security Payload29Authentication Header

18

lä tavalla.Asymmetrisessä tavassa lähettäjä luo yksityisellä avaimella digitaalisen allekir-

joituksen ja vastaanottajat voivat varmentaa tuon lähteen yleisellä avaimella, eivät-kä itse pysty pelkällä yleisellä avaimella luomaan vastaavaa allekirjoitusta, joka loisiväärinkäytön mahdollisuuden. Tällainen menetelmä on hyvä, mutta kuluttaa paljonkaistaa ja on täten epätehokas.

Symmetrisessä tavassa, jota TESLA pääasiassa käyttää, on kaistan kulutus ja las-kentatehon vaatimukset vähäisempiä. TESLA:ssa on käytössä myös aikaviivästettyavaimen paljastaminen, josta johtuen käyttäjien pitää synkronoida kellonsa lähettä-jän kanssa, jotta voivat varmistaa viestin aitouden. Käytännössä TESLA toimii si-ten, että lähettäjä liittää jokaiseen pakettiin mukaan MACin30, jonka se laskee käyt-tämällä sillä hetkellä vuorossa olevaa avainta yksisuuntaisesta salausavainketjus-ta. Lähettäjä paljastaa avaimen tietyn ennalta sovitun ajan kuluttua. Vastaanottajat,jotka ovat suorittaneet aikasynkronoinnin lähettäjän kanssa voivat nyt puskuroidapaketteja siihen asti, että he saavat tuon tietyn aikavälin jälkeen lähetetyn avaimenselville. Kun on tarkistettu, että avain on sovitun kaltainen, voidaan sen avulla tar-kistaa onko puskurissa olevassa paketissa oleva MAC oikea ja sen perusteella jokohyväksyä tai hylätä paketti.

12.1 TESLA:n käyttö SRTP:ssä

Baugherin ja Carraran luomassa dokumentissa[11]esitellään tehohäviöttömän to-dennuksen käyttö turvatussa reaaliaikaisen datan kuljetusprotokollassa (SRTP31).Baugher ja Carrara ovat tehneet lisäyksen TESLA:an, jotta voidaan taata datan läh-teen todennus ryhmälähetyksissä ja yleislähetyksissä.

SRTP on reaaliaikaisen datan kuljetusprotokolla, joka suojaa lähetystä monin ta-voin, mutta se ei kuitenkaan nykyisellään määrittele mitään mekanismia, jolla voi-taisiin taata datan lähteen todennus. TESLA:n liittäminen osaksi SRTP:tä kuitenkintäyttää useiden ryhmälähetyssovelluksien kaipaaman lähteen todennustarpeen, sil-lä se on aiemmin käytettyä digitaalista allekirjoitusta kevyempi.

13 Yhteenveto

Kuten tutkielmasta varmasti tuli esille, on ryhmälähetysten turvaaminen monimuo-toinen ja vaikea prosessi toteuttaa. Toteutuksessa pitää ottaa huomioon asiat aina

30Message Authentication Code31Secure Real-Time Transport Protocol

19

avaintenhallinnasta fyysiseen toteutukseen. Tästä syystä onkin hyvä, että on pe-rustettu IETF:n toimesta työryhmä, joka on luonut ja luo edelleen kehysrakenteitaavuksi niille, joilla on tarvetta käsitellä ryhmälähetyspalveluita turvatussa ympäris-tössä.

Tässä tutkielmassa esitetyt MSEC-työryhmän luomat ratkaisut ryhmälähetyk-sien salaukseen ja salausavainten hallintaan voidaan jossain määrin esittää kuvan 5mukaisina suhteina.

Kuva 5: MSEC-työryhmän luomien ratkaisujen yhteydet

Kuten kuva osoittaa kaikki ratkaisut pohjautuvat tavalla tai toisella neljännes-sä luvussa esiteltyyn ryhmälähetyksien turvallisuusarkkitehtuuriin. Ryhmälähetyk-sien turvallisuusarkkitehtuurissahan kuvattiin niin fyysinen arkkitehtuuri kuin myösturvattuun yhteydenpitoon vaaditut elementit, eli turvallisuuskäytännöt, turvalli-suuspolitiikka, sekä datan käsittelyn välttämättömyys.

Tarkemmin turvallisuuskäytäntöihin ja niiden käyttöön otettiin kantaa viiden-nessä luvussa esitellyssä avaintenhallinta-arkkitehtuurissa. Turvallisuuskäytännötovat tarkoitettuja jäsenten rekisteröintiin, avaimien jakamiseen ja päivittämiseen,sekä itse datan turvaamiseen.

Käytännön toteutuksia avaintenhallinta-arkkitehtuurissa esiteltyihin turvallisuus-käytäntöihin esiteltiin taas luvuissa GDOI, MIKEY, GKDP ja GSAKMP. Edellä mai-

20

nituista MIKEY on tarkoitettu lähinnä nopeaksi rekisteröintiprotokollaksi kun taasGDOI ja GKDP (entiseltä nimeltään GDOIv2) GSAKMP:in kanssa ovat kokonais-valtaisempia turvallisuuskäytäntöjen hallintaprotokollia. GSAKMP:in määrittelys-sä otetaan myös kantaa ryhmälähetysten turvallisuusarkkitehtuurissa esiteltyyn fyy-sisen puoleen, tosin se on identtinen verrattuna siihen.

Kymmenennessä luvussa esitelty ryhmäpolitiikkapoletti on rakenne, joka pitääsisällään ryhmän turvallisuuspolitiikan. Esimerkiksi GSAKMP käyttää politiikka-polettia hyväkseen ryhmälähetysryhmien hallinnassa.

TESLA ja RSA/SHA-1 allekirjoitukset ovat taas datan käsittelyyn liittyviä mää-rittelyjä. Niiden avulla voidaan todentaa esimerkiksi paketin lähde ja sen koskemat-tomuus.

Kaiken kaikkiaan edellä esiteltyjen menetelmien käyttö käytännössä riippuu pal-jolti laitevalmistajista, sillä monet tässä tutkielmassa esitellyt menetelmät ovat vieläkehitysasteella, josta johtuen laitteistoista ei välttämättä löydy tukea kaikille me-netelmille. Kuitenkin ryhmälähetyksille näyttäisi tulevaisuudessa olevan tarvettamultimediapalvelujen kysynnän jatkuvan lisääntymisen vuoksi, joten salaukseenja avainten hallintaan käytetyt menetelmät tulevat todennäköisesti standardisoitu-maan pian. Standardisoinnin seuraus on luonnollisesti se, että laitevalmistajat rea-goivat siihen siten, että heidän valmistamansa laitteet tukevat näitä menetelmiä.

Viitteet

[1] Jyväskylän yliopisto, Palveluiden laadun hallinta laajakais-taverkoissa (Palhala), saatavilla WWW-muodossa <URL:http://www.jyu.fi/it/laitokset/mit/tutkimus/

tietoliikenteen_tutkimus>, viitattu 5.11.2005.

[2] Msec workgroup, Multicast Security (msec), saatavilla WWW-muodossa<URL: http://www.ietf.org/html.charters/msec-charter.html>,lokakuu 2005.

[3] M. Baugher, B. Weis, T. Hardjono, H. Harney, The Group Domain of Interpretation,RFC3547, heinäkuu 2003.

[4] T. Hardjono, B. Weis, The Multicast Group Security Architecture, RFC3740, maa-liskuu 2004.

[5] J. Arkko, E. Carrara, M. Naslund, K. Norrman, MIKEY: Multimedia InternetKEYing, RFC3830, elokuu 2004.

21

[6] M. Baughner, R. Canetti, L. Dondeti, F. Lindholm, Multicast Security (MSEC)Group Key Management Architecture, RFC4046, huhtikuu 2005.

[7] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe, Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Intro-duction, RFC4082, kesäkuu 2005.

[8] H. Harley, U. Meth, A. Colegrove, G. Gross, Group Secure Associa-tion Key Management Protocol, saatavilla WWW-muodossa <URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp

-sec-10.txt>, huhtikuu 2005.

[9] M. Euchner, HMAC-authenticated Diffie-Hellman for MIKEY, saatavillaWWW-muodossa <URL: http://www.ietf.org/internet-drafts/

draft-ietf-msec-mikey-dhhmac-11.txt>, toukokuu 2005.

[10] Brian Weis, The Use of RSA/SHA-1 Signatures within ESP and AH, saatavil-la WWW-muodossa <URL: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-06.txt>, kesäkuu 2005.

[11] Baugher, Carrara, The Use of TESLA in SRTP, saatavilla WWW-muodossa<URL: http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-05.txt>, lokakuu 2005.

[12] A. Colegrove, H. Harney, Group Policy Token v1, saatavilla WWW-muodossa<URL: http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-04.txt>, syyskuu 2005.

[13] Carrara, Lehtovirta, Norrman, The Key ID Information Type for the Ge-neral Extension Payload in MIKEY, saatavilla WWW-muodossa <URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-newtype-

keyid-03.txt>, joulukuu 2005.

[14] A. Milne, M. Blaser, D. Brown, L. Dondeti, ECC Al-gorithms For MIKEY,saatavilla WWW-muodossa <URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-

ecc-00.txt>, kesäkuu 2005.

[15] D. Ignjatic, L. Dondeti, F. Audet, P. Lin, An additional mode of key di-stribution in MIKEY: MIKEY-RSA-R, saatavilla WWW-muodossa <URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-

rsa-r-01.txt>, lokakuu 2005.

22

[16] Brian Weis, George Gross, Dragan Ignjatic Multicast Extensions to the Secu-rity Architecture for the Internet Protocol, saatavilla WWW-muodossa <URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-

extensions-00.txt>, kesäkuu 2005.

[17] L. Dondeti, J. Xian GKDP: Group Key Distribu-tion Protocol , saatavilla WWW-muodossa <URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-gkdp-

00.txt>, syyskuu 2005.

23