Kryptoprotokollat, luento 4 (A), 23.2.2009

• M. Abadi, R.Needham: Prudent Engineering Practice for Cryptographic Protocols, IEEE Trans. on Software Eng., Vol 22, No 1, Jan 1996, 6-15. (alunperin vuodelta 1994)

  Jos sattuisi niin, ettet ehdi lukea kaikkea täksi kerraksi, niin etsi tekstistä ainakin periaatteet 1-11 ja lue myös niiden edellä tai jäljessä oleva muutaman kappaleen mittainen selitys. Tällä kerralla esitellään periaatteet ja käydään läpi artikkelissa olevia esimerkkejä. Toiseen luentoon liittynyt Abadin tuoreempi artikkeli tarjoaa hyvän pohjan tälle artikkelille merkintöjen ja protokollan osien tarkoitusperien kannalta. Kurssin B-osassa myöhemmin käsiteltävä BAN-logiikka on niinikään "samaa sukua".

• Ensi kerralla: R.Anderson, R.Needham: Robustness principles for public key protocols (Crypto'95). Tämä on jatkoa edellä käsitellylle artikkelille ja ensi kerralla on siis luvassa lisää sääntöjä protokollien suunnitteluun. Artikkeli on tämänkertaista abstraktimpi ja siinä on vähemmän "selkeitä" esimerkkejä.

Tietoturvaprotokollan suunnittelun yleisiä periaatteita

Artikkelissa käytetyt merkinnät ovat varsin havainnollisia ja samanlaisia kuin yleensäkin kryptoprotokollia kuvaavassa kirjallisuudessa, joskin sopivasti erilaisia kuin tällä kurssilla tähän asti (erityisesti luennolla 2). Lukemista helpotetaan esim. alaindekseinä ilmaistavilla vihjeillä siitä, kenen avaimista kulloinkin pitäisi olla kyse. Tällaiset vihjeet ja itse protokollan rakenne pitää kuitenkin muistaa tulkita riittävän "karusti". Esimerkkinä on ilmaisu "Viesti 4   B --> A: X", joka sisältää vain seuraavan: "Protokollan suunnittelija on tarkoittanut, että X esiintyy protokollan neljäntenä viestinä siten, että B lähettää sen ja vastaanottajana on A."

Seuraavassa ovat päivän tekstin yksitoista periaatetta tiivistettyinä ja varustettuna enemmän tai vähemmän kuvaavalla yhden sanan mittaisella otsikolla (sekä useat lyhyellä selityksellä). Kaksi ensimmäistä periaatetta ovat kattavimpia. Osa muista on näiden seurauksia tai erikoistapauksia.

1. Merkityssisältö. Jokaisen viestin täytyisi ilmaista merkitys: viestin tulkinta saisi riippua vain sen sisällöstä (eli tulkintaa ei saisi jättää kontekstin varaan).
2. Toimintaehdot. Ehdot, joilla viestin on tarkoitus aiheuttaa toimenpiteitä, pitää eritellä riittävän tarkasti, jotta protokollaa tarkasteleva voi ratkaista, ovatko ne hyväksyttävissä niissä olosuhteissa, joissa hän aikoo protokollaa soveltaa. (Hyväksytäänkö esimerkiksi avaimenvaihtoon sellainen protokolla, jonka tuottamaan symmetriseen avaimeen toinen osapuoli ei voi lainkaan vaikuttaa, vrt. myös esimerkki 11.2.)
3. Nimeäminen. (Kohdan 1 välitön seuraus:) Jos osapuolen identiteetti on oleellista viestin merkitykselle, se pitäisi mainita viestissä eksplisiittisesti.
4. Salaussyy. On oltava selvillä siitä, mihin tarkoitukseen salausta kulloinkin käytetään. (Mahdollisia tarkoituksia ovat luottamuksellisuus, autenttisuus, viestin osien sitominen toisiinsa ja satunnaislukujen tuottaminen. Sekaannus on todennäköisempi symmetrisessä salauksessa.)
5. Salausjärjestys. Jos osapuoli allekirjoittaa jotain, joka on jo salattua, ei pidä olettaa että hän tietää salatun sisällön. Toisaalta, jos osapuoli ensin allekirjoittaa viestin ja sitten salaa sen, on syytä olettaa, että hän tuntee sisällön. (Tiivistefunktio voidaan tässä yhteydessä jossain tapauksessa rinnastaa salausalgoritmiin.)
6. Satunnaisuuskytkentä. On oltava selvillä, mitä ominaisuuksia oletetaan nonce-luvuilta, kun niitä käytetään eri tarkoituksiin. Tyypillisin tarkoitus on kahden viestin ajallisen järjestyksen osoittaminen, mutta viestien muunkinlainen kytkentä toisiinsa on mahdollinen. (Nonce-word = tilapäismuodoste, tekaistu sana; For the nonce = toistaiseksi.) Nonce-luvun yleisenä ideana on olla uusi, riittävän suuri ja satunnainen, jolloin sen keksijä nähdessään sen uudestaan jossain tietää, että tuo esiintymä on syntynyt sen jälkeen kun hän keksi ja lähetti luvun - ja mahdollisesti liittyy muutenkin siihen hänen viestiinsä, jossa luku ensimmäisen kerran esiintyi. (Esimerkissä 6.1 on näytetty, miten nonce sitoo myöhemmän viestin oikeaan osapuoleen, mutta kirjoittajien suositus on silti osapuolen nimen mainitseminen.)
7. Toistosuojaus. Ennustettavissa olevaa suuretta (esim. laskurin arvoa) voi käyttää uutuuden varmistamiseen, mutta se on suojattava niin, ettei sitä voi käyttää myöhemmin replay-hyökkäykseen. (Artikkelin terminologiassa nonce-käsite kattaa myös tällaiset ennustettavissa olevat suureet. Myös aikaleimoissa on ennustettavuutta.)
8. Aikaleimaus. Jos absoluuttiseen aikaan viittaavia aikaleimoja käytetään tuoreuden varmistamiseen, niin paikallisten kellojen eron täytyy olla paljon pienempi kuin se, minkä ikäisten viestien katsotaan olevan voimassa. (Periaatetta edeltävässä esimerkissä 7.1 on luonnosteltu ajan synkronointiin tarvittavia protokollia, joissa ei tietenkään voi käyttää aikaleimoja tuoreuden osoittamiseen. Periaatteen loppuhuomautus muistuttaa aikaleimoihin pohjautuvan systeemin edellyttävän luottamusta ajan hallinnointiin.)
9. Avaintuoreus. Tuore käyttöyhteys ei tee avaimesta tuoretta. (Jos vanhaa avainta voi tällä tavoin perusteetta luulla tuoreeksi, saattaa tarjoutua tilaisuus hyökkääjälle, joka yrittää "virvoittaa" ja ottaa käyttöön selville saamansa avaimen.)
10. Dekoodaus. Viestissä käytetty koodaus pitää pystyä selvittämään itse viestistä. Tämän lisäksi pitäisi voida tunnistaa protokolla, mikä ilmentymä protokollasta ja monesko viesti ko. ilmentymän puitteissa. Tämä periaate on alisteinen sille, miten viestien merkitys on muuten tuotu esille niissä, ja mahdollisia koodauksia käytettäessä riittää (ja täytyy) varmistaa, että merkitysperiaatteet edelleen toteutuvat.
11. Luottamus. Protokollan suunnittelijan tulee tietää mihin luottamussuhteisiin protokolla perustuu ja miksi kyseinen riippuvuus on välttämätön. Syiden pitää olla eksplisiittisiä, vaikka ne eivät perustuisikaan logiikkaan. Tässä kohden artikkeli pohtii lyhyesti luottamuksen olemusta. Esimerkkeinä tässä kohdassa mainitaan:
    • Aikaleimat voivat joskus edellyttää luottamusta.
    • Ei ole välttämättä suotavaa, että toinen osapuoli yksin määrää yhteisen avaimen.
    • Luottamuksen transitiivisuus ei ole itsestään selvää.
    • Pitää mainita, jos oletuksena on molempien osapuolten rehellisyys.
    • Pääsynvalvontalistat sisältävät ilmaisun luottamuksesta, mutta niiden tausta voi olla epämääräinen.

Tarkastellaan lähemmin artikkelin tarjoamia esimerkkejä. Niissä käytetään abstrakteiksi jätettäviä kryptoprimitiivejä, jotka oletetaan sinänsä turvallisiksi. Käsitellään erityisesti seuraavat esimerkit, joissa on rikottu periaatteita 3, 5 ja 9 ja jouduttu vaikeuksiin:

• 3.1: Denning-Sacco-protokolla, jossa A toimittaa B:lle keksimänsä symmetrisen avaimen ja käyttää autentikointiin palvelimelta saamiaan sertifikaatteja omalle ja B:n julkiselle avaimelle.
• 3.4: varhainen SSL, jossa asiakas A yrittää autentikoitua palvelimelle B käyttäen tämän julkista avainta ja oman julkisen avaimensa sertifikaattia.
• 5.1: X.509-standardiin kuuluva yksiviestinen autentikointiprotokolla, jolla tavoitellaan allekirjoitettua yksityisyyden säilyttävää viestintää.
• 5.2: tiivistefunktion ja salauksen vastaavuus "tietämättömyyden" osalta.
• 9.1: Needham-Schroederin symmetrisen avaimen protokolla, jonka tavoitteena on olioiden autentikointi ja avaimen muodostaminen siten, että saavutetaan varmistus siitä, että avain on näiden olioiden hallussa.
• 3.2: Woo-Lam. Tässä kertautuu useampi periaate. Ensi kerralla tulee esille (artikkelissa) samojen tekijöiden julkisen avaimen protokolla.
• 4.1: Kerberos-protokolla on korjailtu muunnos Needham-Schroederin protokollasta. Kerberokseen palataan myös "BAN"-artikkelin yhteydessä B-osassa. Samoin tapahtuu X.509-protokollan kolmiviestiselle versiolle sekä Needham-Schroederin protokollan julkisiin avaimiin perustuvalle versiolle.

Artikkelissa esitetyt periaatteet kannattaa muistaa kurssin kaikissa myöhemmissä vaiheissa. Periaatteiden kunnollinen ymmärtäminen voi edellyttää palaamista aika ajoin lukemaan artikkelin esittämiä selityksiä ja esimerkkejä. Edellä mainitut ovat vain poimintoja. Harjoituksena sopii tässä vaiheessa tarkastella, miten periaatteet toteutuvat 2. luennon protokollissa, jotka ovat yksinkertaisempia kuin useimmat artikkelin esimerkit.