IPSec, Kokonaisuus ja arviointia (2-A)

Verkkokerroksen kryptografialla, erityisesti siis IPSecillä, on etuna tietty joustavuus verrattuna alemmalla tasolla tapahtuvaan linkittäiseen salaukseen tai ylemmän tason sovellusten väliseen suojaukseen (myös esim. SSL:ään). Verkkokerroksen suojatoimet? voidaan nimittäin asettaa minkä tahansa soveliaiden verkkoelementtien välille: päästä-päähän-salaus asettuu kahden isäntäkoneen välille ja reunalta-reunalle-salaus kahden turvallisen verkon välille turvattoman verkon yli. Voidaan myös suojata jonkin tietyn reitin kautta kulkeva liikenne.

Riippumatta siitä, mille välille halutaan, mitä ( AH:ta vai ESP:tä? vai molempia), millä algoritmeilla ja miten (tunneloiden vai ei), tarvitaan aluksi avainten vaihtoa kommunikoivien koneiden välillä. Tämä toteutetaan sovellustason protokollalla IKE (Internet Key Exchange)InternetKeyExchange?)?topicparent=Tietoturva.IPSec,KokonaisuusJaArviointia(2-A)" rel="nofollow" title="Create this topic">? . Sen avulla osapuolet neuvottelevat yhteydenpidon turvaparametrit eli turva-assosiaation SA.

Tällä tasolla esiteltynä IPSec vaikuttaa luontevalta ja hyödylliseltä protokollalta. Tarkempia esittelyjä lukiessa (tässäkin materiaalissa) kannattaa punnita monipuolisuuden hintaa. Ferguson ja Schneier esittävät artikkelissaan Cryptographic Evaluation of IPsec? varsin kriittisiä huomautuksia tästä protokollasta, jonka he silti toteavat olevan parasta, mitä IP:n turvaamiseksi on tarjolla. Artikkeli on vuodelta 1999 ja koskee siis IPSec-määrittelyjä jotka olivat RFC:issä 2401-2409 vuodelta 1998. Tuoreemmat määrittelyt ovat vuodelta 2005 ja niiden RFC:t ovat 4301-4307. Kokonaisuus esitellään näistä ensimmäisessä: Security Architecture for the Internet Protocol? .

Sitä mukaa kun uusien määrityksien mukaisia IPSec-toteutuksia tehdään ja otetaan käyttöön, tarvitaan myös uusia arviointeja. Todennäköisesti aika paljon Fergusonin ja Schneierin kritiikistä jää silti voimaan.

Päällimmäinen moite näyttää olevan, että IPSec on liian mutkikas voidakseen olla turvallinen. Tekijöiden periaatteena on: Monimutkaisuus on turvallisuuden pahin vihollinen (vrt. yleiset periaatteet? ). Muina yleisemmänluonteisina oppeina IPsec-arvioinnistaan he kirjaavat seuraavat.

Oppi 1: Kryptoprotokollia ei pidä laatia komiteatyöskentelyllä.

Oppi 2: Järjestelmän dokumentaation tulisi sisältää johdattelevaa materiaalia, yleiskatsaus niitä varten jotka lukevat asiasta ensi kertaa, asetetut päämäärät, periaatteiden selitykset ja tehtyjen valintojen perustelut.

Oppi 3: Viestin lisäksi pitää autentikoida kaikki, mikä vaikuttaa viestin merkityksen määräytymiseen. (Kirjoittajat luonnostelevat taustaksi hyökkäyksen, jossa paketti todetaan autenttiseksi AH:n perusteella, mutta väärän avaimen takia siitä purkautuukin ESP:llä väärä eli epäautenttinen sisältö).

Oppi 4: Järjestelmässä käytettäviltä primitiivisiltä funktiolta (kuten IPSecin hash- ja pseudorandom-funktiolta) vaadittavien ominaisuuksien pitäisi olla selkeästi dokumentoitu.

Oppi 5: Protokollan on varmistettava, että jokainen allekirjoituksen tai MAC:n autentikoima merkkijono varustetaan merkinnöillä sen tarkoituksesta järjestelmässä. Jokainen merkkijono pitää voida jäsentää osakenttiinsä ilman asiayhteyteen liittyvää tietoa.

Kirjoittajien tärkeimmät suositukset IPsecin suhteen ovat:

  1. Transport-moodi tulisi poistaa. Tunneloinnin aiheuttama paketin koon kasvu voidaan suurimmaksi osaksi kompensoida tiivistämällä.
  2. AH-protokolla pitäisi poistaa saman tien. Myös ESP:llä voi toteuttaa pelkän autentikoinnin, eikä IP-kehyksen tietojen autentikoimattomuus ole kovin vaarallista.
  3. Näiden seurauksena, ja muutenkin, ESP pitäisi muuntaa tarjoamaan aina myös autentikointi ja vain salauksen pitäisi olla valinnaista.
  4. (Oppi 3:n seuraus) ESP:tä pitäisi muuntaa niin, että se autentikoi kaiken datan, jota käytetään kuorman salaamiseen, erityisesti siis myös avaimen. Ehdollisena suosituksena tässä yhteydessä tulee esille ESP:n suorittaman autentikoinnin ja salauksen järjestyksen vaihtaminen niin että autentikointi tapahtuisi ensin.
  5. Protokolla vaatii, että DES:iä käytettäessä pitää välttää käyttämästä heikkoa tai puoliheikkoa avainta. Tämä vaatimus pitäisi poistaa. Sen sijaan pitäisi välttää käyttämästä salausalgoritmeja, joissa on suuria turvattomien avaimien joukkoja.

-- JukkaKoskinen?

SivuTiedotLaajennettu edit

Vaativuus Perus
Valmius Valmisteilla
Tyyppi Ydin
Luokitus Uhkat
Mitä Luottamuksellisuus
Miltä Ihmisetön uhka
Missä Organisaatio
Kuka Tite-ammattilainen
Milloin Ennakolta
Miksi Hyvä tapa
Print version |  PDF  | History: r2 < r1 | 
Topic revision: r2 - 26 Sep 2010 - 11:10:21 - MarkoHelenius
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback