Kryptoprotokollat, luento 11 (A) 27.4.2009

• IKE v2:n kertausta ja arviointia, myös suhteessa sen vaihtoehtoihin
• Minimalistinen autentikointiprotokollien luokittelu
• Avainten hallinnasta ryhmäviestinnässä (= tämän kerran uusi asia)

IKE v2:n kertausta, arviointia, vaihtoehtoja

Tutkittavina ovat nyt siis protokollat, joita voidaan käyttää luomaan avaimet ja muu turva-assosiaatio, eli SA, kahden IPSec-osapuolen välille. Tällaisia protokollia tai ehdotuksia sellaisiksi ovat:

• IKE, eli tarkemmin IKE versio 1. Se on ollut esillä TTJ-kurssilla (id=297). Sitä sopii verrata luennon 2 yleiseen listaan erilaisista autentikointiprotokollista.

• IKEv2: Internet Key Exchange (IKEv2) Protocol RFC 4306 joulukuulta 2005. Keskeinen ero IKE:n versioon 1 verrattuna on mainittu jo johdantoluvussa: Kahdella viestinvaihdolla (=4 viestillä) luodaan paitsi IKE_SA myös ensimmäinen turva-assosiaatio ESP:tä ja/tai AH:ta varten. Jälkimmäistä SA:ta kutsutaan nimellä CHILD_SA ja sellaisia voi myöhemmin luoda lisää, mikä vastaa versiossa 1 aina tarvittua vaihetta 2 ('phase 2'). Lisää eroja versioiden 1 ja 2 välillä on mainittu kohdassa Appendix A. Yksi tärkeä muutos on erilaisten autentikointitapojen toteuttaminen samoilla neljällä ensimmäisellä viestillä siten, että vain yhtä kenttää muutetaan.

• JFK: "Just Fast Keying: Key Agreement In A Hostile Internet" (W.Aiello ja kuusi muuta kirjoittajaa; ACM Trans. Inf. Syst. Sec. 2004). Protokollasta on kaksi versiota JFKi ja JFKr sen mukaan kumpaa osapuolta, aloittavaa (i) vai vastaavaa (r), suojataan identiteetin ennenaikaiselta paljastumiselta. Jälkimmäistä versiota on pidetty todennäköisempänä konvergenssissa IKEv2:n kanssa. JFK:n kehittely IETF-standardiksi loppui luonnokseen nro 04 vuodelta 2002. IKEv2:n RFC ei mainitse JFK:ta, mutta kaikki JFK:n kirjoittajat mainitaan sen tekijöinä ja siinä on havaittavissa JFK:lle asetettujen tavoitteiden toteutumista. Nämä tavoitteet olivat:
  • Turvallisuus: kukaan muu kuin osapuolet ei saa tietoa avaimesta.
  • PFS eli Perfect Forward Secrecy otetaan tavoitteeksi parametrin tapaan: sitä kohti pyritään, mutta siitä voidaan tinkiä jos muut seikat vaativat. PFS tarkoittaa, että jos istuntoavainten muodostamisen pohjana oleva pitkäikäinen avain paljastuu, aiempien istuntoavainten suojaama data pysyy silti salaisena. Parametrinkaltaisuus muodostuu erityisesti siitä aikavälistä, johon avaimen paljastuminen vaikuttaa.
  • Yksityisyys: vrt. i- ja r-version tarkoitus edellä.
  • Muisti-DoS:n torjunta.
  • Laskenta-DoS:n torjunta vastaajan päässä.
  • (Saatavuus, 'availability': Ei saa olla mahdollista helpoilla keinoilla aiheuttaa protokollakohtaisia DoS-hyökkäyksiä. Tätä kohtaa ei ole IETF-luonnoksessa eikä sitä selitetä artikkelissa. Vaatimuksen toteutumista on ilmeisen hankala näyttää toteen.)
  • Tehokkuus laskennan, viestien koon ja niiden määrän suhteen.
  • Neuvottelemattomuus: ei pidä antautua mutkikkaisiin neuvotteluihin osapuolten toiveiden ja kykyjen suhteen.
  • Yksinkertaisuus: muiden vaatimusten puitteissa protokollan pitää olla mahdollisimman yksinkertainen. Tätä JFK toteutti (toisin kuin IKEv2) mm. jättämällä pois avainten uudistamisen ("lapsi-SA:n muodostamisen"). Sen sijaan JFK vain ajetaan uudestaan.
  Alkuperäistä JFK-protokollaa on verifioitu sekä Pi-laskennalla (Abadi, Blanchet, Fournet, 2003) että ACL2:lla Applicative Common Lisp (D.Rager 2006)

• HIP, Host Identity Protocol, joka sekin oli esillä TTJ:ssä ja kerrataan nyt sen mukaisesti (id=395, ks. myös HIP:n IETF-luonnokset ja informationaalinen arkkitehtuuri RFC4423 vuodelta 2006).

Arviointiperusteita

• alttius DoS-hyökkäykselle ja erityiset torjuntamekanismit. Peruskysymykset tässä ovat,
  • kumpaa osapuolta suojellaan DoS:lta, tyypillisesti vastaajaa (palvelinta); millainen olisi DoS aloittajaa vastaan:
  • missä vaiheessa osapuoli joutuu tallettamaan tilatietoa;
  • missä vaiheessa osapuoli joutuu tekemään raskasta laskentaa;
  • minkä verran laskentaa voi tehdä
    • etukäteen;
    • kertaalleen ja käyttää uudestaan, jolloin joudutaan tinkimään jostain muusta ominaisuudesta, erityisesti PFS-turvasta.
• osapuolten identiteetin paljastuminen
  • salakuuntelijalle (passiiviselle hyökkääjälle);
  • toiselle osapuolelle (joka voi olla aktiivinen hyökkääjä); missä vaiheessa.
• menettelyn joustavuus, skaalautuvuus.

Minimalistinen autentikointiprotokollien luokittelu

• D.Park, C.Boyd, and E.Dawson, "Classification of Authentication Protocols: A Practical Approach", Proceedings of Information Security Workshop (ISW 2000), Springer-Verlag, LNCS Vol.1975, pp.194-208.

Luokittelu muistuttaa hieman luennolla 2 tehtyä protokollatyyppien kartoitusta, mutta on abstraktimpi ja käsittelee vain julkisen avaimen protokollia. Esittelyn jälkeen arvioidaan tällaisen luokittelun hyödyllisyyttä.

Allaolevassa taulukossa ovat kaikki järkevät mahdollisuudet, joilla osapuolen A väitetty identiteetti voi tulla osoitetuksi todentajalle B. Kuten välittömästi näkyy, useat esimerkit eivät edusta kokonaisia protokollia. Esimerkkien tarkoituksena on karsia jostain protokollasta pois kaikki, mikä ei liity ko. autentikointityypin olemukseen. Useissa tapauksissa B ei esimerkeissä saa mitään tietoa A:sta. Silti B tietää, ettei väärä A pysty toimimaan, koska vain oikealla A:lla on julkista avainta APubKey vastaava yksityinen avain APriKey. Erityisesti implisiittisen autentikoinnin tapauksessa A:n toimet vain edellyttävät häneltä yksityisen avaimen tietämistä ilman että avaimiin liittyviä viestejä esiintyisi. Kohteen autentikointi muistuttaa tätä, mutta siinä esiintyy kyseisenlaisia viestejä. Lähteen autentikointi edustaa sitä, mitä yleensä nähdään kokonaisissa protokollissa, mutta sekä implisiittistä että kohteen autentikointia esiintyy julkaistuissa protokollissa. Artikkeli mainitsee esimerkkejä liitteessään, jossa tarkastellaan autentikointia molempiin suuntiin.

Autentikoinnin tyyppi		Esimerkki
Implisiittinen a. (IA)	IA_{}	A vain laskee: APriKey{ B }
	IA_F	A <-- B: rB A vain laskee: APriKey{ B, rB }
Lähteen a. (OA)	OA_{}	A --> B: APriKey{ B }
	OA_S	A --> B: TSA, APriKey{ B, TSA }
	OA_F	A <-- B: rB A --> B: APriKey{ B, rB }
Kohteen a. (DA)	DA_{}	A <-- B: APubKey{ B }
	DA_F,NoAck	A <-- B: APubKey{ B, rB }
	DA_F,Ack	A <-- B: APubKey{ B, rB } A --> B: rB

Merkinnät {}, S ja F autentikointityypeissä viittaavat haasteiden käyttöön viestien tuoreuden osoittamisessa. Merkintä {} tarkoittaa, ettei mitään tuoreuden takeita esitetä. Tämä tietysti vähentää näiden protokollien järkevyyttä toistohyökkäysten kannalta. Merkintä S tarkoittaa, että A on itse luonut "haasteen" ja se on tällöin tietenkin TS, time stamp. Merkintä F ('forced') osoittaa, että haasteen (r_B)on keksinyt todentaja. Kuten voinee arvata, merkinnät NoAck ja Ack viittaavat siihen kuittaako A haasteen vai ei.

N.L.Foster arvioi väitöskirjassaan (2002) edellä luonnosteltua ja toista, yksinkertaisempaa, protokollakehikkoa suunnittelijan kannalta seuraavasti:

The aim of the pair of frameworks is to allow designers to consider the items which need to be included in the protocol. It allows the designers to determine which properties are important for particular types of protocols. The framework developers [29, 112] suggest that the frameworks could be used in protocol analysis, to point to weak protocols and find methods to fix them, by comparing the protocols with other protocols within the same class in order to learn from their development. Being able to classify the protocols also allows the re-use of existing protocols or protocol components, as well as design and analysis knowledge.

Whilst research into frameworks has only dealt with key-establishment and authentication protocols, this technique could be applied to other types of protocols, to provide a comprehensive framework for designing protocols in general.

One problem with this method is that the protocols are only being classified based upon confidentiality or authentication properties, other security properties may be considered to be equally as important to different protocol designers. However, should more properties need to be considered, the framework will rapidly become very complex.

Another concern about this method is that the abstract protocols have not been proven to be secure, indeed some of the example protocols in the authentication framework are not secure.

Furthermore, no reasoning or proof has been given to show that all possible instantiations of the abstract protocols are secure: the security of the refinement of the abstract protocol to its concrete representation has also not been addressed. Whilst the frameworks can provide potential approaches to the design of protocols, they only address the issue of ensuring that the protocol under development is actually secure through its comparison with other protocols in the same class.

Avainten hallinnasta ryhmäviestinnässä

• S. Rafaeli, D. Hutchison: A survey of key management for secure group communication ACM Computing Surveys, Vol.35, No.3, Sep 2003,, pp. 309-329.

Kun jäsenmuutoksia tulee, kaikki joutuvat vaihtamaan avainta, mutta tätä varten riittää tehdä laskelmia puussa yläpuolella olevista muuttuneista tiedoista, jotka KDC on lähettänyt multicast-viestinä. Riippuen menettelystä ja siitä, missä kohdassa jäsen sijaitsee muuttuneeseen jäseneen verrattuna, laskuaskelia tulee väliltä 1..h, missä h on puun korkeus. Multicast-viestissä puolestaan on menetelmästä riippuen h tai 2h salattua avainta. Tarkempi kuva pitää opetella luennolta tai artikkelista (ja seuraavista 2 kpl:sta). Kiinnostuneiden kannattaa katsella myös taulukkoja III ja IV, joissa on vertailtu eri protokollia varsin monen muuttujan suhteen.

Jäsenen poistumista OFT-järjestelmässä ei ole selitetty artikkelissa. Poistuvan jäsenen rinnakkaiselle eli sisarussolmulle (sibling) annetaan tällöin uusi oma KEK ja poistuvan jäsenen KEK jätetään tyhjäksi. Jäljelle jääneen jäsenen avain itse asiassa nousee tasoa ylemmäs puussa. Vastaavat tiedot riittää toimittaa kaikille kuin jäsenen lisäystilanteessa.

Artikkelissa mainittu OFT-menetelmän sekoitusfunktio f(x,y) voi olla esim. XOR. Tämä tekee ymmärrettäväksi, miksi artikkelissa joissain kohdissa f(g(x),g(y)):n sijasta sanotaan ja merkitään, että g(x) on salattu y:llä ja välillä että g(y) on salattu x:llä. Tässä g on laskuissa mukana oleva hash-funktio.