Oppikerta 5, 9.2.1999

Avaintenhallinta (jatko)

Kolmas osapuoli T aiheuttaa joka tapauksessa ongelman: ei näet ole osapuolta, johon kaikki luottaisivat, ja vaikka olisikin, ei yksi sellainen pystyisi hoitamaan kaikkea - varsinkaan jos tarvitaan fyysinen yksilöinti rekisteröitymisen yhteydessä (itse asiassa vastaava toimitus pitäisi tehdä avaimen päivityksen yhteydessä - ainakin mikäli tämä tehdään sen vuoksi, että vanha on saattanut paljastua!). Standardi X.509 muodostaa varmenneviranomaisista puurakenteen, jolloin saadaan kohtuullisen läheisillä (ja siis luotettavissa olevilla) ja kokoisilla varmennepalvelimilla (lapsisolmujen määrä) ja kohtuullisella vaivalla (puun syvyys) katetuksi laaja käyttäjäjoukko.

Yleinen varmennestruktuurin idea on seuraava: A vakuuttuu B:n avaimen aitoudesta käyttäen polkua A - X1-X2-...- Xn -B, jossa A luottaa X1:n avaimen aitouteen sekä jokaiseen olioon Xi, ja A:lla on käytettävissään kunkin Xi:n allekirjoittama varmenne X(i+1):n avaimesta ja vielä Xn:n varmenne B:n avaimesta (vrt. esimerkki 11.3. tämän kerran artikkelissa). Tätä mallia voidaan sitten toteuttaa puumaisesti kuten X.509:ssä tai verkkomaisesti kuten PGP:ssä tai näiden välimuotona. Perusmalli sinänsä voi tarvita täydennystä seuraavista syistä:

  1. polun pidetessä voi tapahtua luottamuksen heikkenemistä, jota voidaan mallintaa sumean logiikan tyyppisillä menetelmillä.
  2. pitää voida ottaa huomioon vaihtoehtoiset polut.
  3. luottamus voi perustua suosituksiin, jolloin A luottaa olioon T, jota on suositellut yksi tai useampi olio, joihin A luottaa.
Keskusteltavaksi: Miten Ainon ja Bertilin tapaus siis pitäisi mielestäsi ratkaista?

Avaimen hallinta yleisemmin
Avaintenhallinta (key management) on toimintaa, jonka tarkoituksena on mahdollistaa avaimia edellyttävä kommunikaatiosuhde sellaiseen oikeutettujen osapuolten välillä. Avaimilla tarkoitetaan paitsi julkisia ja symmetrisiä avaimia, myös alustusarvoja ja muita kryptoalgoritmien parametreja. Avaintenhallintaan liittyviä toimia:
  1. uusien käyttäjien tarvitsemat alustukset
    sekä avainmateriaalin
  2. luonti, jakelu ja asentaminen,
  3. käytön (siis käyttötarkoituksen) kontrolli,
  4. päivitys, peruuttaminen, hävittäminen ja
  5. talletus, varmuuskopiointi/palauttaminen, (etukäteinen) pakkoluovutus (escrow).
Avaintenhallinta edellyttää luottamusta tiettyihin ihmisiin, laitteisiin ja ohjelmiin. Yleisenä tavoitteena on minimoida järjestelmän kompleksisuus näiden sekä ylläpidettävien avainten määrän suhteen. Yksi esimerkki tällaisesta optimoinnista on viime kerran alun harjoituksessa keksitty avainten kerrostaminen (siis esim. pääavaimeen, jolla salataan avaimen salausavain, ja alimman tason useimmin vaihdettavaan avaimeen, jota käytetään datan salaukseen). Toinen esimerkki on luotetun kolmannen osapuolen käyttö; sellaisen avulla näet kunkin osapuolen riittää ylläpitää vain yhtä pitkäaikaista avainta.

Harjoitus: Oletetaan, että jokaisella osapuolella (A, B, ...) on oma symmetrinen avaimensa, joka on myös avainkeskuksen KC tiedossa. Keksi (ainakin) neljä protokollaa, joilla A ja B voivat luotettavasti sopia yhteisestä symmetrisestä avaimesta KC:n avulla. (Piirrä kaavio!)

Vastaus: Jos KC toimii avaintenjakelukeskuksena (KDC) saadaan kaksi mahdollisuutta: KC antaa A:n ja B:n omilla avaimilla salatun avaimen joko A:n kautta myös B:lle tai suoraan kummallekin. Jos KC toimii avaintenvälityskeskuksena (KTC, key translation center) saadaan vastaavat kaksi mahdollisuutta: KC lähettää A:lta saamansa (salatun) avaimen B:lle joko A:n kautta tai suoraan. [HAC:546]

Harjoitus: Äskeisessä harjoituksessa ilmeni kaksi seuraavista kolmesta mahdollisesta roolista, joita kolmannella osapuolella T voi yleisesti olla, Mitkä kaksi? Mikä olisi esimerkki kolmannesta?

Off-line-T ei yleensä ole mahdollinen kun hallittavana on salaisia avaimia. Toisaalta julkisen avaimen systeemin salaista avainta ei tarvitse hallinnoida kuin omistajan. On-line-vaatimus koskee siis vain symmetrisen avaimen systeemejä.

Toisentyyppinen jaottelu oli viime kerran artikkelissa: varmenneviranomainen (CA) voi olla joko "in-house" tai yrityksen ulkopuolelta ostettu palvelu (jollaisesta käytetään termiä third-party CA !).

Harjoitus: Millainen on avaimen elinkaari sellaisen avaimen tapauksessa, jota "hallinnoidaan"? Miten hallinnassa pitäisi ottaa huomioon tilanne, jossa avain katoaa tai muuten häviää? Entäpä mitä pitäisi voida tehdä, jos joku ilmeisesti käyttää avaintaan rikollisiin tarkoituksiin? Laadi kooste kaikenlaisista asioista, joita avaimen elinkaaren aikana voi tapahtua ja esitä ne vuokaaviona. Mallina ovat seuraavat vaiheet (ei välttämättä peräkkäiset), jotka [HAC:577-] esittää, myös vuokaaviona.

  1. käyttäjän rekisteröityminen: alustavan avainmateriaalin hankinta, kertaluonteisella turvallisella tavalla.
  2. käyttäjän suorittamat alustustoimet: ohjelmistoasennukset ja rekisteröintiin liittyvät asennukset
  3. avaimen luominen: käyttäjä tekee itse tai saa luotetulta osapuolelta, ja vakuuttuu avaimen tarkoituksenmukaisista turvaominaisuuksista.
  4. avaimen asentaminen
  5. avaimen rekisteröinti: erityisesti julkisen avaimen tapauksessa (jolloin samalla myös julkaiseminen).
  6. avaimen käyttö: päättyy tietyn määräajan (cryptoperiod) jälkeen avaimen päivitykseen.
  7. avaimen varmuuskopiointi
  8. avaimen päivittäminen (update): ei edellytä uutta rekisteröintiä, mutta kylläkin protokollien toteuttamista, mahdollisesti kolmannen osapuolen kanssa (varmenneviranomaisen jos kyse on julkisesta avaimesta).
  9. arkistointi (eri asia kuin varmuuskopio)
  10. avaimen poisrekisteröinti (de-registration) ja hävittäminen
  11. avaimen palauttaminen (recovery): varmuuskopioista
  12. avaimen peruuttaminen (revocation): tilanteessa jossa avaimen arvellaan paljastuneen.
Tästä luettelosta puuttuu kaksi aiemmin mainittua asiaa: avaimen pakkoluovutus (key escrow) ja avaimen käytön kontrolli. Edellinen tarkoittaa sellaisia järjestelmiä, joissa viranomaiset voivat saada avaimen väkisin selville heille etukäteen annetun tiedon perusteella. Tämä tapahtuu (toivon mukaan) vain tietyissä erikoistilanteissa ja silloinkin vain laillisin perustein. (Termi pakkoluovutus on Kerttulan kirjasta; kuvaisiko pakkotalletus paremmin sitä, että escrow tapahtuu joka tapauksessa eli ennen kuin mitään on tapahtunut?).

Avaimen käytön kontrollissa ei ole kyse lainmukaisuuden valvonnasta, vaan siitä että tietyn avaimen käyttö rajoitetaan tiettyihin tehtäviin. Esim. samaa RSA-avainta voisi periaatteessa käyttää hyvin moneen eri tarkoitukseen, mutta tämä ei olisi järkevää turvallisuuden kannalta. Tyypillisiä rajoituksia on vaatia, että avainta käyttää vain tietty omistaja, tiettynä kelpoisuusaikana, tietyssä algoritmissa/protokollassa, tiettyyn tarkoitukseen: salaus (minkä tason...), allekirjoitus (minkä asian), avaimenvaihto,... . Keskeinen menetelmä avaimen K käytön rajoittamiseksi on sitoa K ns. kontrollivektoriin C, joka ilmaisee tarkoitetun käytön. Tämä tapahtuu yhdistämällä C avaimensalausavaimeen L eli salaamalla K avaimella C XOR L. Avaimen K käyttö edellyttää siis oikeita aikomuksia (oikea C), oikeita oikeuksia (oikea L) ja lisäksi luotettavuutta: kun K on saatu selville, sitä käytetään vain C:n mukaisesti.

Kooste kolmannen osapuolen rooleista
Edellä on tullut esille kolmas osapuoli avainten hallinnan yhteydessä. On muitakin tilanteita jossa luottamusta pitää hakea erillisestä palvelusta. Seuraavassa mainitaan aiemmin esille tulleet kolmannen osapuolen roolit ja muutama uusi [HAC:548].

Julkisen avaimen sertifikaatteihin liittyen;

Avaintenhallintaan liittyen yleisemmin: Muita palveluja ("advanced") Aikaleimauksesta. Harjoitus: Keksi esimerkkejä tilanteista, joissa olisi tarpeen voida osoittaa, että jokin tieto oli / ei ollut olemassa ennen tiettyä hetkeä. Millaisia keinoja (perinteisesti) on olemassa näihin tarkoituksiin?

Aikaleimapalvelun tehtävänä on antaa käyttäjälle tämän dokumenttiin liittyvä kuitti siitä, että ko. dokumentti oli olemassa viimeistään tietyllä hetkellä. Jos osapuoleen T luotetaan, T voi palvella aikaleimaajana allekirjoittamalla vastaanottamansa dokumentit yhdessä kulloisenkin ajanhetken kanssa. Dokumentin sijasta allekirjoitus voi tietenkin kohdistua dokumentin tiivisteeseen. Tästä on se hyöty, ettei itse dokumenttia tarvitse paljastaa T:lle.

Ei liene mitään (tietoteknistä) keinoa osoittaa, että jokin tieto olisi ollut olemassa aikaisintaan jonain tiettynä hetkenä, ts. ettei sitä ollut ennen ko. hetkeä.

Aikaleimoja voidaan käyttää viestien osana protokollissa, estämään toistohyökkäyksiä, joissa vastustaja lähettää jonkin vanhan viesti uudestaan. Leima pitää tietenkin suojata salauksella.

Aikaleimat tulevat uudelleen esille pian - autentisointiprotokollien yhteydessä. Harjoitus: Miten voit ilman aikaleimaa vakuuttua, että toisen osapuolen vastaus sinulle on lähetetty oman edellisen viestisi jälkeen? Tuletko samassa yhteydessä vakuuttuneeksi jostain muustakin?

Notarisoinnista. Allekirjoituksen notarisointi on aikaleimauksen ohella yksi mahdollinen ratkaisu sellaiseen kiistämättömyysongelmaan, jossa allekirjoittaja tahallaan paljastaa avaimensa ja kiistää sitten aiemmankin allekirjoituksensa. Notarisointia voidaan toteuttaa myös yleisemmin, jolloin todistettavana on jotain muutakin kuin allekirjoitus.

Autentisoinnin käsitteestä

Jatkossa tutkitaan protokollia ja erityisesti autentikointiprotokollia yleisellä tasolla. Esitetään sitä ennen yhteenveto autentisoinnin käsitteestä, joka on paitsi keskeinen myös monitahoinen. Käsite ja minkä aitoudesta siinä on kysymys [HAC:492]: (Jäi kotona luettavaksi.)
autentisointi (authentication)
riippuu yhteydestä
olion a. (entity a.)
osapuolen identiteetti sekä aktiivisuus (aliveness) tietyllä hetkellä
alkuperän a. (data origin a.)
tiedon lähteen identiteetti
(implisiittinen) avaimen a.
mahdollisesti avaimen jakavan osapuolen identiteetti
avaimen varmistus (key confirmation)
osoitus siitä että tietty avain on jonkun osapuolen hallussa
eksplisiittinen avaimen a.
osoitus siitä että tietty avain on tietyn osapuolen hallussa
Käytännön esimerkki oli nähtävissä GSM-artikkelissa. Siinä autentisoitiin ilman julkista avainta. Autentisointia käsitellään osana seuraavaa aihepiiriä.

Tietoturvaprotokollan suunnittelun yleisiä periaatteita

Seuraavassa ovat Abadin & Needhamin artikkelin yksitoista periaatetta tiivistettyinä ja varustettuna enemmän tai vähemmän kuvaavalla yhden sanan mittaisella otsikolla. Kaksi ensimmäistä periaatetta ovat kattavimpia. Osa muista on näiden seurauksia tai erikoistapauksia.
  1. Merkityssisältö. Jokaisen viestin täytyy ilmaista merkitys: viestin tulkinta saa riippua vain sen sisällöstä.
  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.
  3. Nimeäminen. (1==>) 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: luottamuksellisuus, autenttisuus, viestin osien sitominen toisiinsa, 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. (Esim. viestien ajallinen peräkkäisyys vai muu kytkentä toisiinsa.)
  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.
  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.
  9. Avaintuoreus. Tuore käyttöyhteys ei tee avaimesta tuoretta.
  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.
  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:
Tarkastellaan (ensi kerralla) lähemmin joitakin artikkelin tarjoamia esimerkkejä. Niissä käytetään abstrakteiksi jätettäviä kryptoprimitiivejä, jotka oletetaan sinänsä turvallisiksi.

Luettavaksi: R.Andersson, R.Needham: Robustness principles for public key protocols (Crypto'95). Tämä on tavallaan jatkoa edellä käsitellylle artikkelille.