Verkkojen tietoturva Luentomateriaali, kevät 2006 Timo Karvi HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Sisältö 1 IPSEC ja VPN-verkot 1 1.1 Yleiskatsaus IPSECiin.......................... 1 1.2 IPSEC-arkkitehtuuri........................... 2 1.2.1 Arkkitehtuurin yleiskuva..................... 2 1.2.2 Turvayhteydet........................... 3 1.2.3 Turvapolitiikan tietokanta.................... 4 1.3 Todennusotsake.............................. 5 1.3.1 Uudelleenlähetysten esto..................... 6 1.3.2 Eheyden tarkistusarvo...................... 6 1.3.3 Kuljetus- ja tunnelimoodi.................... 7 1.3.4 Ongelmia............................. 8 1.4 Koteloitu salattu data.......................... 11 1.4.1 Salaus- ja todennusalgoritmit.................. 11 1.4.2 Kuljetus- ja tunnelimoodi.................... 12 1.5 AH:n ja ESP:n toiminta kuvioina.................... 13 1.6 Turvayhteyksien yhdistäminen...................... 18 1.7 IPSECin kritiikkiä............................ 25 1.7.1 IPSECin dokumentointi..................... 25 1.7.2 Datan käsittely.......................... 26 1.7.3 Operaatioiden järjestys...................... 26 1.7.4 Turvayhteydet........................... 27 1.7.5 Turvapolitiikat.......................... 27 1.8 IPSECin avaintenhallinta......................... 28 1.8.1 Aloitus............................... 28 i
ii SISÄLTÖ 2 Yleiskatsaus langattomaan teknologiaan 31 2.1 Langattomat verkot............................ 31 2.1.1 WLAN:it............................. 32 2.1.2 Ad hoc -verkot.......................... 32 2.2 Langattomat päätelaitteet........................ 32 2.2.1 PDA:t............................... 33 2.2.2 Älypuhelimet........................... 33 2.3 Langattomat standardit......................... 33 2.3.1 IEEE 802.11............................ 33 2.3.2 Bluetooth............................. 33 2.4 Langattomat turvallisuusuhat ja riskien vähentäminen........ 34 2.5 Uudempia langattomia sovelluksia.................... 35 3 WLAN 37 3.1 Yleiskatsaus................................ 37 3.2 Arkkitehtuuri ja protokollat....................... 37 3.2.1 Arkkitehtuuri........................... 38 3.2.2 Protokollat............................ 39 3.3 WLAN:in tietoturva yleisesti....................... 42 3.4 SSID ja WEP yleisesti.......................... 43 3.5 RC4-jonosalaus.............................. 44 3.6 WLAN:in tietoturvan ongelmia..................... 46 3.6.1 Julkiset WLAN:it......................... 46 3.6.2 Kontrolliviestit.......................... 46 3.6.3 MAC-osoitteisiin perustuva ja muu todentaminen....... 47 3.6.4 WEP:in tietoturvaongelmat................... 47 3.7 WLAN:in tietoturvan parantaminen................... 51 3.7.1 Tietoturvan parantaminen lähiverkon suunnittelulla...... 52 3.7.2 Turvakomponentit........................ 52 4 Bluetoothin tietoturvasta 55 4.1 Johdanto.................................. 55 4.2 Bluetooth fyysisesti............................ 55 4.3 Bluetoothin arkkitehtuuri........................ 56
Luku 1 IPSEC ja VPN-verkot 1.1 Yleiskatsaus IPSECiin IPSEC on IP-verkkoprotokollien laajennus, millä estetään IP-pakettien urkkiminen ja muuntaminen. IPSEC on syntynyt uuden IPv6-protokollan yhteydessä ja IPv6 onkin IPSECin luonteva alusta. IPSEC voidaan kuitenkin sovittaa myös IPv4- protokolliin. Verkkotason suojaus ei vaikuta sovellusohjelmiin tai sovellusprotokolliin ja IPSEC-paketteja voivat käsitellä jo käytössä olevat reitittimet ja reitittävät isäntäkoneet. Seuraavassa luetellaan IPSECin sovelluksia: Yritys voi rakentaa turvallisen virtuaalisen yksityisen verkon Internetin tai julkisen WAN-verkon yli. Tämä mahdollistaa sen, että yritykset voivat luottaa Internetiin ja säästää yksityisen verkon perustamis- ja käyttökustannukset. Loppukäyttäjä, jolla on IPSEC implementoituna, voi ottaa paikallisen yhteyden Internetin palveluntarjoajaan, jota kautta hän voi edelleen saada turvallisen yhteyden yrityksensä suljettuun verkkoon. Tämä vähentää kaukopuhelukuluja. IPSECiä voidaan käyttää varmistamaan kommunikointi toisten organisaatioiden kanssa niin, että todennus ja luottamuksellisuus taataan. IPSEC lisää elektronisen kaupankäynnin turvallisuutta. Paitsi että IPSEC takaa loppukäyttäjien kommunikoinnin turvallisuuden, se on tärkeässä asemassa myös reitityksessä. Seuraavassa on muutamia tärkeitä sovelluksia reititykseen. Reitittäjän ilmoitukset siitä, että se on tullut mukaan toimintaan, saadaan valtuutetulta reitittimelta. Muiden ilmoitukset voidaan hylätä. Samoin kun reitittäjä etsii naapureitaan, etsintä voi perustua valtuutettujen reitittimien toimintaan. 1
2 LUKU 1. IPSEC JA VPN-VERKOT Uudelleenreititysohjeet tulevat reitittimeltä, joka todella aloitti pakettien reitityksen. Reititystietojen päivitykset eivät ole väärennettyjä. 1.2 IPSEC-arkkitehtuuri 1.2.1 Arkkitehtuurin yleiskuva IPSEC on varsin monimutkainen ja terminologiakin on erikoista. Protokolla on suunniteltu toteuttamaan luottamuksellisuus (salauksen avulla) ja todennus. Kummallekin suojaustavalle on määritelty oma otsikkonsa, koteloitu salattu data ja todennusotsikko. Yksi ja sama IP-paketti voi sisältää yhden tai molemmat otsikot riippuen tarvittavasta turvapalvelusta. Todennusotsikko (AH, Authentication Header) sisältää eheyden tarkistustietoa, millä voidaan tarkistaa, onko paketti väärennös tai onko sitä muutettu matkalla epäluotettavan verkon läpi. Otsikko sisältää tätä varten tarkistussumman. Tarkistussumma sisältää salaista tietoa, josta syystä ulkopuolinen ei pysty laskemaan toista tarkistussummaa, mikä osoittaisi sisällön aitouden. Koteloitu salattu data -otsikkoa (ESP, Encapsulating Security Payload) käyttämällä salataan paketin loppuosan datasisältö. ESP-otsikon muoto vaihtelee sen mukaan, mitä salausalgoritmia käytetään. Kaikissa tapauksissa käytettävä salausavain valitaan parametrin SPI (security parameter index) avulla. IPSEC-protokolla koostuu siten kahdesta versiosta, joista toinen kattaa pelkästään todennuksen todennusotsikon avulla. Toinen versio on yhdistetty todennusja salausprotokolla, jonka yhteydessä käytetään otsikkoa koteloitu salattu data yksinään tai todennusotsikon kanssa, jos halutaan salauksen lisäksi todennus. IPSEC tarjoaa kuitenkin enemmän kuin pelkästään yksinkertaisen todennuksen ja salauksen. Seuraavassa on lueteltu IPSECin tarjoamat palvelut: Pääsynvalvonta. Yhteydetön eheys. Datan alkuperään liittyvä todennus. Toistohyökkäysten torjunta. Luottamuksellisuus. Rajoitettu liikennevirran luottamuksellisuus.
1.2. IPSEC-ARKKITEHTUURI 3 1.2.2 Turvayhteydet Turvayhteydet (security associations) on avainsana toteutettaessa todennusta ja luottamuksellisuutta. Kummankin IPSEC-suojaukseen pyrkivän isäntäkoneen tulee muodostaa aluksi turvayhteys toinen toiseensa. Turvayhteys määrittelee, mitä ja miten IPSEC-suojausta käytetään, eli mitä turvapalvelua milloinkin käytetään, miten salaus ja/tai todennus suoritetaan ja mitä avaimia pitää käyttää. Eli turvayhteys sisältää kaiken sen informaation, mitä tarvitaan luotettavan yhteyden määrittelemisessä ja toteutuksessa. IETF:n dokumentit käsittelevät turvayhteyttä ja sen sälytyspaikkaa, SAD:ia (security association database), hypoteettisinä käsitteinä, koska ne ovat osapuolten sisäisiä asioita. Ne sisältävät kommunikoinnin kannalta oleellisia tietoja, mutta itse SA kokonaisuudessaan ei ole osa kommunikointia. Sen tähden dokumentit eivät ota kantaa sen muotoon tai sijaintiin. Käytännössä SAD on taulukko, jota säilytetään suojatussa muistissa, ja SA on tietue taulukossa. Jokainen turvayhteys sisältää tietoa, jonka avulla IPSec-prosessi voi päättää, sovelletaanko SA:n määrittelemää suojaa tiettyyn lähtevään tai tulevaan pakettiin. Ratkaisu tehdään SA:n valitsimien (selectors) perusteella. Valitsimet sisältävät seuraavaa: Lähde- ja kohdeosoite. Toistaiseksi sallitaan vain yksittäiset osoitteet, ei yleislähetyksiä. Kohdeosoite voi olla joko loppukäyttäjä tai palomuuri tai reititin. Nimi on joko käyttäjätunnus tai systeemin nimi. Käyttäjätunnus rajaa SA:n vain erityisen käyttäjän aloittamaan tai vastaanottamaan kommunikointiin. Jos ainoat valitsimet ovat kommunikoivien osapuolten käyttäjätunnuksia, SA:ta kutsutaan käyttäjäsuuntautuneeksi (user-oriented). Jos taas käytetään systeeminimiä, se rajaa liikenteen tiettyjen systeemien välille. Systeemi voi olla isäntäkone, turvayhdyskäytävä tms. Kuljetuskerroksen protokolla (TCP tai UDP). Lähde- ja kohdeportti. Yleensä käytetään yhtä ainoaa porttinumeroa, jolla rajataan SA:n käyttö tiettyyn sovellukseen (esim. FTP). Jokainen SA sisältää myös seuraavia tietoja: Järjestysnumerolaskuri on 32 bitin arvo, jota käytetään AH- ja ESP-otsakkeissa järjestysnumeroiden generoimiseen. Järjestysnumeron ylivuoto on lippu, joka osoittaa, kirjataanko järjestysnumeron ylivuodosta lokitapahtuma vai ei. Jos kirjataan, niin seuraavien pakettien lähetys tässä turvayhteydessä on estetty. Uudelleenlähetysikkunaa (anti-replay window) käytetään ratkaisemaan, onko saapunut AH- tai ESP-paketti uudelleenlähetys vai ei.
4 LUKU 1. IPSEC JA VPN-VERKOT AH-informaatio sisältää todennusalgoritmin, avaimet, avainten eliajan ja parametrit, joita tarvitaan AH-paketin ja todennuksen yhteydessä. ESP-informaatio sisältää salaus- ja todennusalgoritmit, avaimet, alustusarvot, avainten elinajat ja muut parametrit, joita tarvitaan ESP:n kanssa. Turvayhteyden elinaika on aikaväli tai tavumäärä, jonka jälkeen turvayhteys täytyy korvata uudella tai päättää. Elinaikaan liittyy vielä tieto, kumpi noista kahdesta on käytössä. IPSECin protokollamoodi tarkoittaa tunneli-, kuljetusmoodia tai villiä korttia, joiden merkitystä selvitetään myöhemmin. Polun MTU (maximum transmission unit) tarkoittaa maksimaalista pakettikokoa, joka voidaan välittää pilkkomatta. Lisäksi paketteihin liittyvät aikamääreet kuuluvat MTU-parametriin. On varsin todennäköistä, että kommunikoivat osapuolet sopivat useammasta kuin yhdestä SA:sta. Esimerkiksi sähköposti ja Web-sovellus vaativat vähemmän kuin maksuja siirtävä protokolla. Kun suojattua pakettia ollaan lähettämässä, lähettäjän täytyy tiedottaa vastaanottajalle, mitä SA:ta on käytetty paketin kohdalla, jotta vastaanottaja tietäisi valita saman SA:n. Tätä palvelee turvaparametri-indeksi (SPI). Koska jokainen SA on yksisuuntainen, turvallinen kaksisuuntainen yhteys vaatii kahden SA:n määrittelemistä: sisään tulevan ja ulos menevän. SPI yhdessä kohdeosoitteen ja turvaprotokollan (AH, ESP) kanssa on riittävä, jotta sisään tulevan paketin SA osataan hakea SAD:sta. Jotta taataan SPI:n yksikäsitteisyys, kumpikin osapuoli valitsee oman sisääntulevan SPI:n. 1.2.3 Turvapolitiikan tietokanta Kaikki liikenne IPSEC-verkoissa jaetaan turvayhteyksiin ja muuhun liikenteeseen. Turvayhteyksiä voidaan yhdistellä monella tavalla halutun tuloksen aikaansaamiseksi. Turvayhteyksiin liittyvää liikennettä säädellään turvapolitiikan tietokannan (SPD) avulla. Yksinkertaisimmillaan SPD sisältää tietueita, joista kukin liittyy tiettyyn osaan IP-liikennettä ja tiettyyn turvayhteyteen. Monimutkaisemmissa tilanteissa moni tietue voi liittyä samaan turvayhteyteen tai moni turvayhteys voi liittyä yhteen SPD-tietueeseen. Tällä kurssilla ei kaikkia mahdollisuuksia käsitellä yksityiskohtaisesti. Jokainen SPD-tietue määritellään IP- ja ylemmän kerroksen kenttäarvojen avulla, joita kutsutaan valitsimiksi (selectors). Näitä valitsimia käytetään suodattamaan ulosmenevä liikenne siten, että se kyetään yhdistämään tiettyyn turvayhteyteen. Ulosmenevän liikenteen käsittely noudattaa seuraavia periaatteita: 1. Etsi paketin sopivien kenttien perusteella liikennettä vastaava SPD-tietue, joka puolestaan viittaa nollaan tai useampaan turvayhteyteen. 2. Poimi SPD-tietueen ja paketin SPI:n perusteella pakettiin liittyvä turvayhteys.
1.3. TODENNUSOTSAKE 5 3. Prosessoi paketti turvayhteyden mukaisesti. SPD-tietueen määrittelemiseksi käytetään seuraavia valitsimia: Kohteen IP-osoite voi olla joko yksittäinen osoite, osoitelista, osoiteväli tai villi kortti -osoite. Jos osoite käsittää useita yksittäisiä osoitteita, niiden haltijat sijaitsevat saman palomuurin takana ja niihin liittyy sama turvayhteys. Lähteen IP-osoite voi myös olla yksittäinen, lista, väli tai villi kortti. Käyttäjätunnus on käyttöjärjestelmään liittyvä käyttäjätunnus. Tätä ei käytetä IP- tai ylemmissä otsakkeissa, mutta se on saatavilla, jos IPSEC toimii saman käyttöjärjestelmän alaisuudessa kuin käyttäjäkin. Tiedon luottamuksellisuusaste on esimerkiksi salainen tai luokittelematon. Kuljetuskerroksen protokolla saadaan IPv4:n tai IPv6:n kentästä Next Header. Se voi olla yksittäisen protokollan numero, lista protokollanumeroita tai protokollanumeroiden väli. IPSEC-protokolla eli AH, ESP tai AH+ESP saadaan samasta kentästä kuin edellinen tieto. Lähde- ja kohdeportit voivat jälleen olla yksittäisiä tai usean portin joukkoja. IPv6-luokka saadaan IPv6:n otsakkeesta. IPv6-vuon merkki saadaan IPv6:n otsakkeesta. IPv4:n palvelutyyppi saadaan IPv4:n otsakkeesta. 1.3 Todennusotsake Todennusotsakkeeseen (AH) perustuva protokolla huolehtii siis tiedon eheydestä ja IP-pakettien todennuksesta. Pakettien todennus varmistaa käyttäjän tai palvelun identiteetin, joiden pohjalta suodatus tapahtuu. AH suojaa myös uudelleenlähetyksiä vastaan. Todennus perustuu MAC-koodiin, joka edellyttää samaa salaista avainta lähettäjällä ja vastaanottajalla. Todennusotsake koostuu seuraavista kentistä: Seuraavan paketin otsakkeen tyyppi (8 b). Hyötykuorman pituus (8 b). Varattu osa ( 16 b). SPI (32 b).
6 LUKU 1. IPSEC JA VPN-VERKOT Järjestysnumero (32 b). Todennustieto (muuttuva). Tämä kenttä sisältää eheyden tarkistusarvon (ICV, integrity check value) tai MAC-arvon. 1.3.1 Uudelleenlähetysten esto Uudelleenlähetysten torjuntaan käytetään AH:n järjestysnumerokenttää. Kun uutta turvayhteyttä perustetaan, lähettäjä alustaa järjestysnumerolaskurin nollaksi. Joka kerran kun paketti lähetetään käyttäen perustettua turvayhteyttä, lähettäjä kasvattaa laskuria ja asettaa sen arvon järjestysnumerokenttään. Siten ensimmäinen arvo on 1. Laskurin suurin arvo on 2 32 1. Laskuria ei saa päästää tämän jälkeen takaisin nollaan, vaan jos lisäpaketteja on tulossa, on perustettava uusi turvayhteys uudella avaimella. Koska IP on yhteydetön, epäluotettava palvelu, protokolla ei takaa, että paketit luovutetaan perille järjestyksessä tai että edes kaikki paketit menevät perille. Siksi IPSEC vaatii, että vastaanottajan on toteutettava ikkuna, jonka oletusarvoinen koko on W = 64. Ikkunan oikea reuna sisältää suurimman tähän asti vastaanotetun järjestysnumeron, N. Jos saapuvan paketin järjestysnumero on välillä [N W + 1, N], vastaava paikka ikkunassa merkitään. Tarkemmin kuvattuna vastaanottopäässä tehdään seuraavaa: 1. Jos saapuneen paketin järjestysnumero sisältyy ikkunan lukuihin ja on uusi, MAC tarkistetaan. Jos todennus onnistuu, järjestysnumeroa vastaava paikka ikkunassa merkitään. 2. Jos saapuneen paketin järjestysnumero menee oikealta ikkunan ulkopuolelle ja on uusi, MAC tarkistetaan. Jos todennus onnistuu, ikkunaa siirretään oikealle niin, että vastaanotetusta järjestysnumerosta tulee ikkunan uusi oikea reuna. 3. Jos saapuneen paketin järjestysnumero menee vasemmalta ikkunan ulkopuolelle tai jos todennus epäonnistuu, paketti hylätään. Hylkäys kirjataan lokiin. 1.3.2 Eheyden tarkistusarvo Eheyden tarkistusarvo on tiivistefunktion tai MACin arvo. IPSECin tulee tarjota ainakin kaksi tiivistefunktiota, HMAC-MD5-95 ja HMAC-SHA-1-96. Molemmat käyttävät HMAC-algoritmia, edellinen MD5-tiivistefunktion, jälkimmäinen SHA-1 -tiivistefunktion kanssa. Kummassakin lasketaan ensin kryptografinen tiivistekoodi, mutta siitä otetaan mukaan vain ensimmäiset 96 bittiä. Tiivistearvo lasketaan seuraavista kentistä: IP:n tunnusosan kentät, jotka eivät muutu liikenteessä tai joiden arvo vastaanotettaessa on ennustettavissa. Kentät, jotka muuttuvat matkalla eivätkä ole ennustettavissa, asetetaan nollaksi tiivistettä laskettaessa.
1.3. TODENNUSOTSAKE 7 AH-otsake paitsi todennustietokenttää, joka asetetaan nollaksi. Kaikki ylemmän tason tieto, joka oletetaan muuttumattomaksi liikenteessä. 1.3.3 Kuljetus- ja tunnelimoodi IPSECin todennuspalvelua voidaan käyttää kahdella tavalla. Näitä tapoja kutsutaan kuljetusmoodiksi ja tunnelimoodiksi. Kuvassa 1.1 nähdään pakettien tilanne ennen AH:n soveltamista. Kuvassa 1.2 puolestaan on pakettien tilanne kuljetusmoodissa AH:n soveltamisen jälkeen. AH todentaa koko kentän mahdollisia muuttuvia kenttiä lukuunottamatta. Huomattakoon, että tilanne on erilainen IPv4:n ja IPv6:n välillä. IPv4 orig IP TCP Data otsake IPv6 orig IP laajennus TCP Data otsake otsakkeet Kuva 1.1: Ennen AH:n soveltamista IPv4 orig IP AH TCP Data otsake IPv6 orig IP hop-by-hop AH TCP Data otsake maali,reititys Kuva 1.2: Kuljetusmoodi Kuljetusmoodia käytetään esimerkiksi kuvan 1.3 tilanteessa, jossa asiakas ja palvelin kommunikoivat suoraan ja niillä on yhteinen salainen avain. Asiakas voi olla joko samassa verkossa palvelimen kanssa tai eri verkossa. Palvelin Salattu TCP yht. Ulko verkko Asiakas LAN Kuva 1.3: Kuljetusmoodin sovellustilanne
8 LUKU 1. IPSEC JA VPN-VERKOT Tunnelimoodissa AH lisätään puolestaan pakettiin kuvan 1.3.3 mukaisesti. Edelleeen todennus koskee koko pakettia muuttuvia kenttiä lukuunottamatta. IPv4 uusi IP AH orig IP TCP Data otsake otsake IPv6 uusi IP laajennus AH orig IP laajennus TCP Data otsake otsakkeet otsake otsakkeet Kuva 1.4: Tunnelimoodi Siis koko alkuperäinen paketti todennetaan ja AH lisätään alkuperäisen IP-otsakkeen ja uuden, ulomman IP-otsakkeen väliin. Sisempi IP-otsake sisältää varsinaisen lähdeja kohdeosoitteen, kun taas ulompi IP-otsake voi sisältää muita, esimerkiksi reitittimien, osoitteita. Tunnelimoodia käytetään tyypillisesti tilanteessa, jossa ulkoinen työasema todentaa itsensä palomuurille päästäkseen sen jälkeen palomuurin suojaamaan verkkoon. Tunnelimoodia käytetään erityisesti rakennettaessa ns. virtuaalisia yksityisiä verkkoja( VPN). 1.3.4 Ongelmia Kuvio 1.5 näyttää tilanteen, jossa AH ei toimi, kun käytössä on IPv4. A lähettää Turvayhdyskäytävä Internet Turvayhdyskäytävä Kone A Kone B Kuva 1.5: Turvayhdyskäytävän luoma ongelma AH:lle
1.3. TODENNUSOTSAKE 9 paketin B:lle varustettuna AH:lla. Koska A:n liikenne menee turvayhdyskäytävän kautta, A:n osoite hävitetään ja korvataan yhdyskäytävän osoitteella. Tämä aiheuttaa sen, että B epäonnistuu todentaessaan pakettia, koska siinä on tehty muutoksia. Samanlainen tilanne esiintyy, jos turvayhdyskäytävän tilalla on NAT-palvelin (network address translation). Se myös muuttaa lähettäjän osoitetta. Kuviossa 1.6 nähdään, miten turvayhdyskäytävät ja NAT:it täytyy konfiguroida systeemiin. NAT Yhdyskäytävä Kone1 Kone2 Kone1 Kone2 Internet Kone3 Kone3 Yhdyskäytävä NAT Kuva 1.6: Turvayhdyskäytävät ja NAT:it systeemissä Vakavampi ongelma liittyy pakettien pilkkomiseen. Oletetaan, että yhdyskäytävien SG1 ja SG2 välille on määritelty AH:n tunnelimoodi, joka suojelee kaikkea liikennettä verkkojen N1 ja N2 välillä. Jos koneelta H1-1 koneelle H2-1 menevä paketti pilkotaan ennen kuin se ehtii yhdyskäytävälle SG1, SG1 laskee erilliset tarkistussummat jokaiselle palselle erikseen ja lähettää ne SG2:lle. Kun palaset saapuvat SG2:lle, ne todennetaan ja palasista kootaan alkuperäinen paketti, joka luovutetaan H2-1:lle. Eli kaikki on hyvin. Jos kuitenkin pilkkominen tapahtuu SG1:n ja SG2:n välissä, syntyy ongelmia. SG1 on laskenut tarkistussumman koko paketille. Vastaanottajan SG2 täytyy nyt laskea tarkistussumma vasta kaikkien palasten saavuttua. Mistä vastaanottaja tietää, kumpaa tapaa noudattaa? Muutetaan edellistä tilannetta hieman. Oletetaan, että SG2 tietäessään polun joidenkin osien tukkeutuvan helposti välttää kasvattamasta pakettien kokoa ja jättää tunnelimoodin pois. Vaikkakaan tämä tapa ei ole IPSec:in määritysten mukainen,
10 LUKU 1. IPSEC JA VPN-VERKOT jotkut toteutukset menettelevät näin. Muutetaan myös verkon rakennetta hieman. SG2:n ohella verkossa on turvayhdyskäytävä SG3, joka myös palvelee N2:ta. Jos kaikki SA:t verkkojen N1 ja N2 välillä noudattavat tunnelimoodia, jonka ovat neuvotelleet SG1 ja SG2, kaikki pakettien palaset reititetään sopivalle yhdyskäytävälle ja prosessointi tapahtuu oikein. Jos kuitenkin SG1 ja SG2 päättävät lyhentää pakettien kokoa ja siirtyvät kuljetusmoodiin, ongelmia syntyy. SG2 perustaa kuljetusmoodin SG1:n kanssa olettaen, että se on ainoa väylä verkkoon N2. Jos nyt palasia reititetään myös SG3:n kautta, palasia ei voida koota yhdyskäytävissä. Nyt on kaksi vaihtoehtoa. Ensimmäisessä SG2 todentaa jokaisen vastaanottamansa palasen ja yrittää kokoamista. Koska kaikki palaset eivät tule SG2:n kautta, kokoaminen epäonnistuu ja paketti hylätään ajastimen lauettua. Sillä aikaa SG3:lle tulevat palaset joko hylätään tai ohjataan edelleen H2-1:lle. H2-1 hylkää palaset, koska ei löydä sopivaa SA:ta niiden käsittelyyn. Toisessa vaihtoehdossa SG2 yrittää koota pakettia ennen todennusta, mutta tämäkin päättyy kuten ensimmäinen vaihtoehto. Nämä tilanteet ovat pahimman tapauksen analyyseja, mutta verkkoympäristössä pahimmat tapaukset näyttävät esiintyvän huolestuttavan usein. Nämä esimerkit näyttävät, miksi IPSec:in turva-arkkitehtuuri vaatii tunnelimoodin yhdyskäytävien välille, jos SA:t suojaavat liikennettä muiden koneiden kuin yhdyskäytävien välillä. Sama pätee yhdyskäytävän ja isäntäkoneen kommunikointiin, jossa yhdyskäytävä suojaa liikennettä muille koneille yhdyskäytävän takana. Jotta vältettäisiin pilkkominen, yhdyskäytävien täytyy viestittää suojaamilleen koneille niiden otsakkeiden koko, jotka yhdyskäytävä lisääkoneiden lähettämiin paketteihin. Alkuperäinen lähettäjä yrittää yleensä lähettää paketteja, joiden koko on mahdollisimman lähellä PMTU:tä (path maximum transmission unit). Lähettämällä pienempiä paketteja, joihin voidaan vielä lisätä tunnelimoodin otsake, saatetaan pilkkominen välttää. On toinenkin tapa välttää pakettien pilkkomista. Lähettävä kone voi tehdä kokeiluja määrittääkseen maksimaalisen PMTU:n paketille ja sitten ottaa tämä huomioon paketteja lähetettäessä. IPv4:än kohdalla tämä merkitsee, että DF-bitti on asetettava, jotta estetään pakettien pilkkominen välisolmuissa. Ja ongelmia taas syntyy. Jos nimittäin paketti on kuitenkin liian suuri koko reitille, välillä oleva reitittäjä lähettää ICMP-sanoman paketti liian suuri lähettävälle koneelle. Tunnelimoodin tapauksessa viesti menee turvayhdyskäytävälle, jonka osoite näkyy lähettäjänä paketissa. Viesti siis tulee välisolmusta, jonka kanssa turvayhdyskäytävä ei ole neuvotellut minkäänlaista turvayhteyttä. Pitäisikö turvayhdyskäytävän uskoa tätä viestiä? Jos se uskoo, tieto täytyy välittää lähettävälle koneelle. Jos taas se ei usko, lähettävä kone jatkaa isojen pakettien lähettämistä, joissa on kaiken lisäksi DF-bitti päällä. Itse asiassa samoja ICMP-viestejä voidaan käyttää myös palvelunestohyökkäyksessä. Ongelma on hankala ja useita ehdotuksia on tehty, kuinka pilkkomiseen tulisi suhtautua. Eräs ehdotus perustuu SG1:n ja SG2:n yhteistyöhön. SG1 sallii H1-1:ltä lähetettyjen pilkottujen pakettien jatkaa matkaansa. Tämän varmistamiseksi SG1 ei aseta DF-bittiä ulkoiseen otsakkeeseen, jos H1-1 on asettanut sen sisempään otsakkeeseen. Kun SG2 saa pilkottuja paketteja, se lähettää PMTU-viestin SG1:lle.
1.4. KOTELOITU SALATTU DATA 11 Viesti ilmoittaa SG1:lle suurimman pakettikoon, joka on menestyksekkäästi matkannut SG1:ltä SG2:lle. Koska SG1:n ja SG2:n välillä on tunnelimoodi, PMTU-viesti on suojattu. Tämä ratkaisu eroaa tavanomaisesta PMTU-viestin käytöstä, koska nyt viesti lähetetään sen jälkeen kun pilkottu pakettu on vastaanotettu. Normaali PMTU-viesti lähetetään silloin, kun paketin lähettäminen eteenpäin ei onnistu. On myös mahdollista, että SG2 sisällyttää PMTU:n käytettävään SA:han ja aika ajoin informoi SG1:tä viimeisimmästä PMTU:sta. Jos H1-1 yrittää lähettää liian suuren paketin, SG1 välittää PMTU:n H1-1:lle. 1.4 Koteloitu salattu data Koteloitu salattu data eli ESP tarjoaa siis salauksen ja haluttaessa myös todennuksen. ESP-otsake koostuu seuraavista kentistä: SPI (sama kuin AH:ssa). Järjestysnumero (AH:ssa). Hyötykuorma on kuljetuskerroksen segmentti (kuljetusmoodi) tai IP-paketti (tunnelimoodi), joka suojataan salauksella. Täyte (0-255 B) selitetään myöhemmin. Täytteen pituus (8 b) on täytteen pituus tavuissa. Seuraava otsake (8 b) määrittelee sen datan tyypin, joka sijaitsee hyötykuormakentässä. Tyyppi määräytyy ensimmäisen tunnusosan mukaan. Todennustieto (AH). 1.4.1 Salaus- ja todennusalgoritmit ESP-palvelu salaa kentät hyötykuorma, täyte, täytteen pituus ja seuraava otsake. Jos salausalgoritmi vaatii esimerkiksi alustusvektorin, se välitetään yleensä kentän hyötykuorma alussa salaamattomana. Alussa määriteltiin, että ESP-toteutuksen täytyy tukea DESiä CBC-moodissa. Jatkossa DESin paikalla on AES. Muita mahdollisuuksia ovat Kolmen avaimen kolminkertainen DES. RC5. IDEA. Kolmen avaimen kolminkertainen IDEA. CAST.
12 LUKU 1. IPSEC JA VPN-VERKOT Blowfish. ESP tukee MACin käyttöä. MAC-arvon oletuspituus on 96 bittiä. Algoritmit ovat HMAC-MD5-96 ja HMAC-SHA-1-96. Täyte Täyte palvelee montaa tarkoitusta. Jos salausalgoritmi vaatii, että selväteksti on tavujen monikerta, selvätekstiin voidaan lisätä täyte. Täyte voidaan lisätä myös salatekstin ja kenttien täytteen pituus ja seuraava otsake väliin. Täytettä voidaan käyttää myös salaamaan hyötykuormakentän todellinen pituus. 1.4.2 Kuljetus- ja tunnelimoodi Samoin kuin AH:n kohdalla myös ESP-protokollaa voidaan käyttää kuljetus- ja tunnelimoodissa. Kuvassa 1.13 nähdään, mitkä kentät salataan ja todennetaan ESPpaketeissa kuljetusmoodissa. IPv4: orig IP ESP TCP Data ESP ESP otsake otsake pääte tod IPv6: orig IP hop-by-hop, kohde ESP kohde TCP Data ESP ESP otsake reititys, palat otsake pääte tod Kuva 1.7: ESP-kuljetusmoodi Kuljetusmoodin toiminta etenee seuraavasti: 1. Lähettäjän puolella ensin salataan kentät 3-5 (IPv4) tai 4-7 (IPv6). Selväkieliset vastaavat kentät korvataan salatekstillä. Todennus lisätään, jos sitä halutaan. Todennus kattaa kentät 2-5. 2. Paketti reititetään kohteeseen. Jokainen välillä oleva reitittäjä tutkii IP-otsakkeen ja selväkielisen laajennusotsakkeen, mutta ei salattua osaa. 3. Vastaanottaja tutkii selväkieliset kentät. ESP-osan SPI-tietojen perusteella vastaanottaja purkaa salauksen. Tunnelimoodissa koko IP-paketti plus ESP-perä salataan. Reititystä varten alkuperäisestä IP-paketista kerätään tarvittavat tiedot, joita käytetään ulomman IPpaketin tunnusosassa. Kuvassa 1.14 näkyy salaukseen ja todennukseen käytetyt kentät. Kuljetusmoodi sopii suojaamaan yhteyksiä kahden koneen välillä, joissa kummassakin on ESP. Tunnelimoodi on hyödyllinen, kun toisena osapuolena on palomuuri tai muu turvallinen yhdyskäytävä, joka suojaa verkkoa ulkopuolisilta. Salaus on
1.5. AH:N JA ESP:N TOIMINTA KUVIOINA 13 IPv4: Uusi IP ESP orig TCP Data ESP ESP otsake otsake otsake pääte tod IPv6: Uusi IP laaj. ESP orig IP laaj. TCP Data ESP ESP otsake otsakkeet otsake otsake otsakkeet pääte tod Kuva 1.8: ESP-tunnelimoodi käytössä tässä tapauksessa yleensä vain ulkoisen koneen ja yhdyskäytävän välillä. Suojatun verkon sisällä salausta ei tarvita. 1.5 AH:n ja ESP:n toiminta kuvioina Seuraavassa esitetään AH:n ja ESP:n toimintaa kuvioiden avulla. Näitä voidaan sitten käyttää hyväksi kuvattaessa havainnollisesti turvayhteyksien yhdistämistä. Aluksi kuvassa 1.9 on tyypillinen tilanne, jossa kahden koneen yhteys on suojattu kuljetusmoodin avulla. Tällä saavutetaan TCP-istunnon salaus. Kuvassa 1.10 puo- Salattu TCP istunto Kone A LAN WAN Kone B Kuva 1.9: Kuljetustason suojaus lestaan on toteutettu virtuaalinen yksityinen verkko IPSecin tunnelimoodin avulla. Kuvasarja 1.11-1.14 puolestaan esittää pakettien muodostumista eri moodeissa. AH ja ESP on käsitelty erikseen, mutta seuraavassa luvussa käsitellään näiden yhdistämistä.
14 LUKU 1. IPSEC JA VPN-VERKOT A Yritys verkko Internet B Kuva 1.10: Virtuaalinen ykstyinen verkko tunnelimoodin avulla
1.5. AH:N JA ESP:N TOIMINTA KUVIOINA 15 IP TCP Data AH IP AH TCP Data Todennus Kuva 1.11: AH kuljetusmoodissa
16 LUKU 1. IPSEC JA VPN-VERKOT IP TCP Data Tunnelointi uusi IP IP TCP Data AH AH Uusi IP IP TCP Data todennus Kuva 1.12: AH tunnelimoodissa IP TCP Data ESP IP ESP TCP Data ESPtrlr ESPauth Salaus Todennus Kuva 1.13: ESP kuljetusmoodissa
1.5. AH:N JA ESP:N TOIMINTA KUVIOINA 17 IP TCP Data Tunnelointi uusi IP IP TCP Data ESP Uusi IP ESP IP TCP Data ESPtrlr ESPauth salaus todennus Kuva 1.14: ESP tunnelimoodissa
18 LUKU 1. IPSEC JA VPN-VERKOT 1.6 Turvayhteyksien yhdistäminen Yksittäinen turvayhteys voi toteuttaa joko AH:ta tai ESP:tä, muttei molempia. Toisinaan kuitenkin tietty liikennevirta saattaa vaatia kummankin palveluja. Edelleen sama liikenne voi edellyttää erilaisia palveluja riippuen siitä, tapahtuuko liikenne isäntäkoneiden välillä vai yhdyskäytävien välillä. Termi turvayhteyksien kimppu (bundle) tarkoittaa yhteyksien jonoa, jonka kautta liikenne täytyy ohjata, jotta saataisiin haluttu IPSEC-palvelu. Turvayhteydet voidaan yhdistää kimpuksi kahdella tavalla: Transport adjacency: Tarkoittaa, että samaan IP-pakettiin sovelletaan useampaa kuin yhtä turvaprotokollaa ilman tunnelointia. Vain yhden tason (kts. seuraavia esimerkkejä, jotta tason käsite tulee selväksi) yhdistelmät ovat järkeviä, sillä luotettava kommunikointi tapahtuu kahden isäntäkoneen välillä. Iterated tunneling: Tässä tavassa turvaprotokollia käytetään usealla tasolla tunnelimoodin yhteydessä. Seuraavassa luetellaan muutamia vaihtoehtoja koota kimppuja. Näissä vaihtoehdoissa yhdistellään salaus ja todennus käyttäen pääasiassa kahta turvayhteyttä, jotka sidotaan kimpuksi. ESP ja todennus. Tässä vaihtoehdossa käyttäjä soveltaa ensin ESP:tä salatakseen tiedon ja sitten lisää tiedon todennuskentän. Tässä on edelleen kaksi alivaihtoehtoa: Kuljetusmoodi. Todennus ja salaus kohdistetaan IP:n hyötykuormaan, mutta IP-otsakkeeseen ei kosketa. Tunnelimoodi. Todennus kohdistuu koko IP-pakettiin, jota ollaan lähettämässä ulkoiseen osoitteeseen. Koko sisäinen IP-paketti salataan. Siis käytetään vain yhtä turvayhteyttä, joka sisältää ESP:n todennusosan kanssa. Transport adjacency. Toinen tapa soveltaa todennusta salauksen jälkeen on käyttää kahta kimppuun sidottua turvayhteyttä. Sisempänä on ESP:n turvayhteys ja ulompana AH:n. Tässä versiossa ESP:iä käytetään ilman todennusoptiota. Koska sisäinen turvayhteys noudattaa kuljetusmoodia, salaus kohdistuu IP:n hyötykuormaan. Tuloksena oleva paketti käsittää IP-otsakkeen, jota seuraa ESP. Sen jälkeen sovelletaan AH:ta kuljetusmoodissa niin, että todennus kattaa ESP:n ja alkuperäisen IP-otsakkeen ja sen laajennukset lukuunottamatta muuttuvia kenttiä. Tämän lähestymistavan etuna verrattuna pelkkään ESP:hen todennusoption kera on siinä, että se sisältää useampia todennettuja kenttiä, mukaan lukien lähe- ja kohdeosoitteen. Haittana on se, että kahden turvayhteyden ylläpito kuluttaa enemmän resursseja kuin yhden.
1.6. TURVAYHTEYKSIEN YHDISTÄMINEN 19 Kuljetus-tunneli-kimppu. Tämä yhdistelmä mahdollistaa todennuksen ennen salausta. Tämä on hyödyllistä tietyissä tilanteissa. Ensiksikin salaus suojaa tässä menetelmässä todennusta väärennöksiä vastaan. Toiseksi joskus on tarpeellista tallentaa todennus kohteessa myöhempää käyttöä varten. Tässä tilanteessa todennuksen kohdistaminen salaamattomaan dataan helpottaa todennuksen käsittelyä myöhemmin, sillä salausta ei tarvitse enää purkaa ensimmäisen kerran jälkeen. Todennus ennen salausta saadaan aikaan kahdella turvayhteydellä. Ensin sovelletaan sisempänä AH:ta kuljetusmoodissa ja sen jälkeen ulompana ESP:tä tunnelimoodissa. Toisin sanoen todennus kohdistuu IP:n hyötykuormaan ja IP-otsakkeeseen lukuunottamatta muuttuvia kenttiä. Tuloksena syntynyt IPpaketti salataan tämän jälkeen ESP:llä tunnelimoodissa, jolloin koko sisempi paketti salataan ja uusi ulompi IP-otsake lisätään alkuun. Perusyhdistelmät IPSECin arkkitehturidokumentti listaa neljä tapausta, joissa turvayhteyksiä yhdistellään ja jotka mahdollisuudet on otettava mukaan IPSEC-toteutuksiin. Nämä tapukset ovat seuraavat: Tapaus 1. Tässä versiossa kaiken suojauksen hoitavat isäntäkoneet, jotka vaihtavat sanomia keskenään. Niillä täytyy olla sopivat salaiset avaimet kummallakin. Mahdollisia turvayhteyskimppuja ovat: a) AH kuljetusmoodissa. b) ESP kuljetusmoodissa. c) AH, jota seuraa ESP kuljetusmoodissa. d) Mikä tahansa a), b) tai c) AH:n tai ESP:n sisällä tunnelimoodissa. Tapaus 2. Turvayhteys on pelkästään yhdyskäytävien (reitittimet, palomuurit) välillä, eikä isännissä ole IPSECiä. Tämä tilanne kuvaa tukea yksinkertaiselle virtuaaliselle yksityiselle verkolle. Turva-arkkitehtuurin dokumentti toteaa, että ainoastaan yksi tunnelimoodissa toimiva turvayhteys on tarpeen. Tunneli voisi perustua AH:lle, ESP:lle tai ESP:lle todennusoption kera. Sisäkkäisiä tunneleita ei tarvita. Tapaus 3. Rakentuu tapauksen 2 päälle lisäten siihen päästä-päähän -turvallisuuden. Samat yhdistelmät kuin edellisissä tapauksissa ovat mahdollisia. Yhdyskäytävätunneli takaa todennuksen tai luottamuksellisuuden tai molemmat loppujärjestelmien välillä. Yksittäiset isäntäkoneet voivat sitten toteuttaa mitä tahansa IPSEC-palveluja, joita tarvitaan sovelluksissa. Tapaus 4. Tarjoaa tukea kaukaiselle isäntäkoneelle, joka käyttää Internetiä päästäkseen organisaation palomuuriin ja sen jälkeen palvelimelle tai työasemaan.
20 LUKU 1. IPSEC JA VPN-VERKOT Tarvitaan vain tunnelimoodi kaukaisen isäntäkoneen ja palomuurin välille. Kuten tapauksessa 1, myös tässä voidaan käyttää yhtä tai kahta turvayhteyttä kaukaisen ja palomuurin sisällä olevan isäntäkoneen välillä. Näytetään vielä kuviona muutamia yhdistelmiä. Kuvioista näkyy pakettien rakenne ja vaiheet, joiden kautta paketti rakentuu. IP TCP Data ESP IP ESP TCP Data ESPtrlr AH salaus IP AH ESP TCP Data ESPtrlr todennus Kuva 1.15: ESP+AH, molemmat kuljetusmoodissa
1.6. TURVAYHTEYKSIEN YHDISTÄMINEN 21 Kone A SA ESP SA AH End to_end ESP,AH Internet Kone B SA ESP SA AH Kuva 1.16: Kuljetusmoodin ESP+AH:n sovellustilanne
22 LUKU 1. IPSEC JA VPN-VERKOT IP TCP Data AH IP AH TCP Data ESP todennus salaus IP ESP AH TCP Data ESPtrlr salaus Kuva 1.17: AH+ESP kuljetusmoodissa
1.6. TURVAYHTEYKSIEN YHDISTÄMINEN 23 IP TCP Data AH IP AH TCP Data todennus Tunnelointi U IP IP AH TCP Data ESP U IP ESP IP AH TCP DataESPtrlr todennus salaus Kuva 1.18: AH kuljetusmoodissa, ESP tunnelimoodissa
24 LUKU 1. IPSEC JA VPN-VERKOT Kone A Intranet Gateway Internet Gateway Intranet Kone B Kuva 1.19: Sovellustilanne, jossa AH kuljetus-, ESP tunnelimoodissa
1.7. IPSECIN KRITIIKKIÄ 25 1.7 IPSECin kritiikkiä IPSEC on syntynyt komiteatyönä, jossa mukana on ollut useita tahoja. Tämä on johtanut siihen tyypilliseen tilanteeseen, että yhteen ja samaan protokollaan on sovitettu monia piirteitä ja näkökantoja. Tällainen suunnittelu on johtanut IPSECin ja monen muunkin protokollan (erityisesti ISOn OSI-protokollat aikoinaan) yhteydessä laajuuteen ja monimutkaisuuteen, joka ei enää palvele käyttäjiä. Näyttääkin siltä, että parempi tulos saavutetaan kilpailujen avulla kuten AES:n yhteydessä. Tällöin yksi ja sama, suppeahko tiimi suunnittelee protokollan, jolloin sen koko pysyy kohtuullisena. Opetus 1. Kryptografisia protokollia ei pitäisi suunnitella komiteatyönä. Seuraavassa käsitellään IPSECin ongelmia kohta kohdalta Niels Fergusonin ja Bruce Schneierin artikkelin A Cryptographic Evaluation of IPsec pohjalta. Esityksessä keskitytään vain varsinaiseen toimintaan. IPSECin avaintenhallinta, jota käsitellään seuraavassa kappaleessa, on ollut koko ajan kehityksen kohteena ja artikkelin kirjoituksen aikana se oli erityisen sekavaa. Siitä syystä emme käsittele artikkelin avaintenhallintaan kohdistuvaa kritiikkiä. Artikkelin kaikki suositukset on esitetty myös tässä. Toisaalta ei ole aivan selvää, että kaikki olisivat artikkelin ehdotuksiin tyytyväisiä. Erityisesti käytännön verkkosuunnittelijan näkökulma saattaa olla toinen kuin pelkästään tietoturvaihmisten. 1.7.1 IPSECin dokumentointi IPSECin dokumentteja on hyvin vaikea ymmärtää. Niissä ei yleensä ole yleiskatsausta tai johdantoa. Siten ei ole uskottavaa, että kukaan oppisi IPSECiä virallisista dokumenteista. Tässä yhteydessä erityisesti mainitaan alustava avaintenhallintaprotokolla ISAKMP, jonka dokumentointi sisältää virheitä, josta monet oleelliset selitykset puuttuvat ja joka on sisäisesti ristiriitainen. Dokumenteista ei käy selville protokollan tavoite. Tällöin protokollan analysointi on hankalaa. Samoin sunnittelijan, joka yrittää soveltaa IPSECiä käytäntöön, työ vaikeutuu. IPSEC tuottaa IP-tason turvallisuutta ja on siten oleellisesti VPNprotokolla. Kuitenkin on ollut tapauksia, jossa protokollaa on käytetty sovellustason turvallisuuden saavuttamiseen kuten esimerkiksi henkilön todentamiseen kun tämä yrittää lukea sähköpostiaan. IPSEC perustaa pakettien todennuksen siihen, että paketti on lähtenyt joltakulta, joka tuntee salaisen avaimen. Kuitenkin monet näyttävät uskovan, että se todentaa lähettävän IP-osoitteen, jota sitten voidaan käsitellä palomuurissa. Dokumentit eivät myöskään sisällä selityksiä tai perusteluja valinnoille, joita on tehty. Vaikka nämä eivät ole niin tärkeitä kuin tavoitteet, ne ovat myös oleellisia. Opetus 2. Systeemin dokumentin tulisi sisältää johdattelevaa materiaalia, yleiskatsaus niille, jotka tutustuvat asiaan ensimmäistä kertaa, asetetut tavoitteet ja perustelut.
26 LUKU 1. IPSEC JA VPN-VERKOT 1.7.2 Datan käsittely Moodit Turvaomisuuksien kannalta katsottuna tunnelimoodi sisältää kuljetusmoodin (verkkokerroksesta katsoen tilanne saattaa olla päinvastainen). Kuljetusmoodi kuluttaa tosin vähemmän kaistanleveyttä. Tunnelimoodiakin voitaisiin tehostaa, joten tekijät suosittavat Suositus 1. Kuljetusmoodi voidaan jättää pois. Dokumenteissa ei perustella kahden moodin olemassaoloa. Kuljetusmoodin poisjättäminen välttäisi myöskin koneiden jakamisen kahteen luokkaa, isäntäkoneisiin ja turvayhdyskäytäviin. Näiden pääero näyttää olevan, etteivät turvayhdyskäytävät voi käyttää kuljetusmoodia. AH ja ESP Dokumentit eivät selitä, miksi IP-otsakkeet pitää todentaa. Hyötykuorman todennus takaa, että kuorma tulee sellaiselta, joka tuntee salaisen avaimen. IP-otsakkeeet vain auttavat pakettia menemään vastaanottajalle eikä niiden pitäisi vaikuttaa paketin tulkintaan. AH todentaa alempien kerrosten IP-otsakkeita. Tämä selvästi rikkoo protokollapinon modulaarisuutta. Se aiheuttaa monia ongelmia, koska jotkut kentät muuttuvat matkan aikana. Siten AH:n täytyy tuntea kaikki alempien kerrosten dataformaatit, jotta muuttuvat kentät voidaan välttää. Tämä ei tunnu järkevältä. Suositus 2. Jätetään AH pois. ESP sallii hyötykuorman salauksen ilman todennusta. Hyvin harvoin salaus ilman todennusta on hyödyllistä. IPSECin yhteydessä tällainen tilanne on kuljetusmoodissa, jossa ESPin todennus ei ole kovin kattava ja on käytettävä lisäksi AH:ta. Jos kuljetusmoodi ja AH jätettäsiin pois, voitaisiin suositella Suositus 3. Muutetaan ESPiä siten, että se tuottaa aina todennuksen; vain salaus voisi olla valinnainen. 1.7.3 Operaatioiden järjestys Kun käytetään sekä salausta ja todennusta, IPSEC salaa ensin ja todentaa sitten. Tämä on Fergusonin ja Schneierin mukaan väärä järjestys. Todentaa pitäisi se, mitä tarkoitetaan, ei sitä, mitä sanotaan. IPSECin todennus mahdollistaa myös hyökkäyksen. Oletetaan, että kaksi konetta ovat neuvotelleet AH:ta käyttävän SA:n, jossa avaimet on jaettu manuaalisesti. Merkitään tätä SA:ta symbolilla SA AH. Koska avaimet on sovittu manuaalisesti, AH ei
1.7. IPSECIN KRITIIKKIÄ 27 tarjoa suojaa uusintahyökkäyksille. Oletetaan nyt, että koneet neuvottelevat kuljetusmoodin ESP:n, jossa käytetään vain salausta. Merkitään vastaavaa turvayhteyttä symbolilla SA ESP1. Tietoa välitettäessä käytetään kimppua, joka koostuu näistä kahdesta turvayhteydestä. Sovellus voi olettaa saavansa tällä tavalla luottamuksellisuuden ja todennuksen, mutta ei suojaa uusinnoilta. Kun kimppuun perustuva yhteys lopetetaan, turvayhteys SA ESP1 puretaan. Muutamia tunteja myöhemmin samat koneet neuvottelevat taas uuden kuljetumoodin ESP:n, jossa on vain salaus (SA ESP2 ) ja vastaanottaja valitsee saman SPI:n arvon kuin edellisen ESP:in yhteydessä. Dataa välitetään taas kimpun avulla, joka sisältää sekä SA ESP2 :n että SA AH :n. Hyökkääjä ujuttaa sanomien joukkoon nyt jonkin vanhan paketin edellisestä istunnosta. Tämä paketti oli salattu SA ESP1 :n avulla ja todennettu SA AH :n avulla. Vastaanottaja toteaa todennuksen päteväksi. (Koska uusintojen suojausta ei käytetä, järjestysnumerokenttää ei käytetä.) Vastaanottaja purkaa sitten salauksen käyttäen SA ESP2 :ta, mikä tuottaa eri tuloksen kuin jos olisi käytetty SA ESP1 :tä. Seurauksena on, että vastaanottaja hyväksyy todennetun paketin, purkaa sen väärällä avaimella ja luovuttaa vääristyneen datan sovellukselle. Eli todennus on epäonnistunut. Opetus 3. Älä todenna pelkästään sanomaa, vaan kaikki se, mitä käytetään sanoman merkityksen määräämiseksi. Salatekstin todennus tekee mahdolliseksi hylätä paketteja nopeasti käyttämättä aikaa salauksen purkamiseen. Tämä auttaa konetta palvelunestohyökkäyksissä. Mikäli tämä koetaan tärkeäksi, salatekstin todennus voidaan säilyttää, mutta vain jos samalla todennetaan purkuavain. Tämä olisi mahdollista, mutta se sotisi pahasti modulaarisuutta vastaan, kun AH joutuisi kaivamaan ESP:n rakenteista salausvaimen. Suositus 4. Modifioi ESP:tä siten, että todentaa datan lisäksi hyötykuorman salauksen purkuavaimen. 1.7.4 Turvayhteydet On aika vähän tilanteita, joissa kone lähettää IP-paketin toiselle, mutta vastusta ei lähetetä eikä oleteta. On myös vähän tilanteita, joissa täytyy turvata liikenne yhteen suuntaan, mutta ei vastakkaiseen suuntaan. Siten lähes kaikissa tilanteissa SA:t esiintyvät pareittain muodostaen symmetrisen kaksisuuntaisen kanavan. Olisi siten selvempää, että SA:t olisivat kaksisuuntaisia. 1.7.5 Turvapolitiikat Turvapolitiikan tietokanta SPD sallii monien valitsimien käytön päätettäessä, mihin pakettiin sovelletaan mitäkin SA:ta. On mahdollista, että yksi SA hoitaa kaiken liikenteen kahden koneen välillä tai että kullakin sovelluksella on oma SA:nsa. Mikäli ylläpidon pitää luokitella paketit sen mukaan, mitkä vaativat IPSEC-prosessointia ja mitkä eivät, vaaditaan ehkä jo liian paljon. Kun lisäksi ylläpidon pitää aset-
28 LUKU 1. IPSEC JA VPN-VERKOT taa lukuisia muita IPSEC-asetuksia salaus- ja todennusmenetelmistä alkaen, on todennäköistä että monet konfiguraatiot sisältävät heikkouksia. 1.8 IPSECin avaintenhallinta Avainten hallintaa ei ole ratkaistu yksikäsitteisesti. IPSEC-avainten hallintaan on olemassa useita ratkaisuja. Vaikka tähän on myös Internet-standardeja, laite- ja ohjelmistotoimittajilla on myös omia ratkaisuja, mikä hidastaa IPSECin nopeaa leviämistä. Tässä kokonaisuudessa on mukana paitsi tekniset näkemyserot myös poliittiset näkemyserot. Tällä hetkellä IPSEcin avaintenhallinta perustuu IKE-protokollaan (Internet Key Exchange). Tämä protokolla on kehittynyt useammassa vaiheessa (Oakley, ISAKMP). ISAKMP oli hyvin monimutkainen ja sen tilalle suunniteltiin IKEv1. Siinäkin on lukuisia vaihtoehtoja, mikä tekee protokollan hankalaksi ymmärtää. Esimerkiksi aloitus voitiin tehdä kahdeksalla eri tavalla. Lisäksi protokolla määriteltiin useassa dokumentissa. IKEv2 on IKEv1:tä suoraviivaisempi, vaikka sekin on monimutkainen. Erityisesti aloitukset on korvattu yhdellä aloituksella, joka käsittää neljä sanomanvaihtoa. Samoin kuin IKEv1 myös IKEv2 on kaksivaiheinen: 1. Aluksi neuvotellaan ja pystytetään IKE-SA, jonka avulla voidaan sitten neuvotella IPSEC-SA. 2. Vaiheessa 2 sovitaan sisäänmenevä ja ulostuleva SA. 1.8.1 Aloitus Aloitus on seuraava: Aloittaja Vastaanottaja ========= ============= 1. HDR, SAi1, KEi, Ni ---------> 2. <--------- HDR, SAr1, KEr, Nr, [CERTREQ] 3. HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, ---------> SAi2, TSi, TSr} 4. <-------- HDR, SK {IDr, [CERT,] AUTH,