-- HansAhrenberg? - 23 Sep 2009

Avainten turvatalletus, "key escrow"

Johdanto

Tämä työ käsittelee avainten turvatalletusta teorian ja käytännön esimerkin kautta. Työssä on tarkoitus selvittää, miksi avainten turvatalletus on tietoturvallisuuden kannalta ylipäätänsä tarpeellista, ja mitä uhkia siihen liittyy. Tarkastelemalla uhkia on mahdollista saada parempi kuva siitä, millaisia vaatimuksia avainten turvatalletusjärjestelmiin voidaan kohdistaa. Käytännön esimerkkinä käsitellään Iso-Britannian lainsäädäntöön kuuluvaa Regulation of Investigatory Powers Act 2000:n sisältämää määräystä avainten turvatalletuksesta [3].

Määritelmä

Käsitellään ensin lyhyesti turvatalletuksen määrittelyssä tarvittavia termejä;

Toimija, käyttäjä, avaimenhaltija = taho, joka toimii sellaisessa ympäristössä, missä avaimen turvatallettaminen on tarpeen.
Avain = kryptoavain, jonka toimija luovuttaa talletettavaksi tahdostaan riippumatta.
Kolmas osapuoli = taho, jolla on keino saada avain haltuunsa, mikäli siihen tarvetta tulee.
Luovutusehto = ehto, jonka täyttyessä kolmas osapuoli on oikeutettu ottamaan talletettu avain käyttöön.

Suppea turvatalletuksen määritelmä voisi olla sellainen tilanne, missä toimija luovuttaa avaimensa talletettavaksi siten, että kolmas osapuoli saa sen käyttöönsä luovutusehdon toteutuessa. Määritelmä ei kuitenkaan vielä ota kantaa siihen, miten turvallinen järjestelmän tulee olla ulkoista hyökkäystä vastaan tai millä taataan se, ettei kolmas osapuoli käytä avainta muulloin kuin luovutusehdon täyttyessä. Lisäksi jätetään tyystin huomiotta tarvittava luottamus kolmanteen osapuoleen. Mikäli toimija on esimerkiksi tietämätön avaimensa turvatalletuksesta, on kyseessä ehkä jokin muu järjestelmä kuin turvatalletus. (vrt. esimerkiksi backdoor) Suppean määritelmän lisäksi on siis turvatalletusjärjestelmään kohdistettava vaatimuksia aina toimintaympäristön mukaan.

Yleistä avainten turvatalletuksesta

Key escrow -termille ei sen luonteen vuoksi ole olemassa suomeksi aivan yksiselitteistä termiä, vaan termin merkitys riippuu vahvasti siitä, mistä näkökulmasta asiaa katsotaan. Avaimen luovuttaja voisi sanoa sitä avaimen pakkoluovutukseksi, kun taas key escrow toiminnon määrännyt taho käyttäisi termiä avainten turvatalletus. Tutkielmassa käytetään sanaa turvatalletus, koska termi on näistä kahdesta ehkä hieman objektiivisempi yleiseen käyttöön. Avaimen turvatalletuksen idea syntyi 90-luvulla Yhdysvaltain Turvallisuusviraston NSA:n 'Clipper chip' -projektin myötä ja on vielä nykyäänkin erilaisissa sovelluksissa osana käytäntöä [2]. Turvatalletuksen taustalla on idea siitä, että avaimen haltijan kieltäytyessä luovuttamasta avainta tai ollessa kyvytön tähän, pystyttäisiin tärkeisiin tietoihin pääsemään käsiksi. Idea on hyvä, sillä esimerkiksi viranomais- ja yritystoiminnassa törmätään usein tilanteisiin, jossa tarvitaan pääsy salattuihin tietoihin. Turvatalletuksesta olisi mahdollisesti hyötyä esimerkiksi tapauksessa, jossa rikosepäilty on haluton antamaan viranomaisten vaatimia salattuja tietoja. Turvatalletuksesta olisi tietysti hyötyä myös niinkin yksinkertaisessa tapauksessa, missä käyttäjä hukkaa avaimensa ja pyytää sitä itse tallesta takaisin.

Perinteisessä turvatalletusjärjestelmässä on kolme osaa, joita ovat talletus- ja palautusosa sekä käyttäjän osa. Käyttäjän osan tehtävänä on normaali selkotekstin salaaminen ja purku. Käyttäjän osa lisää kryptotekstiin myös DRF (data recovery field) tai LEAF (law enforcement access field) kentän, joka pitää sisällään varsinaisen istuntoavaimen, jolla käyttäjä salaa selkotekstiä. Talletusosaksi KRA (key recovery agent) kutsutaan sitä järjestelmän osaa, joka hallinnoi kryptotekstin purkamiseksi eli tietojen palauttamiseen tarvittavia avaimia. Yleensä avainten hallinnointi on jaettu useamman tahon kesken, joiden täytyy toimia yhteistyössä avaimen ja tietojen palauttamiseksi. Palautusosa DRA (data recovery agency) suorittaa tiedon purun talletusosalta saamaltaan turvatalletetulla avaimella. DRA on usein viranomaistaho. [5] [6]

Käyttäjä A <------ kryptoteksti + DRF ------> Käyttäjä B
                                          |
                                          |
                                          |
                                          |
                 KRA <-------> DRA -------> selkoteksti

Työssä käsitellään myöhemmin myös erilaisia ongelmia, joita toteutukseen voi liittyä. Toistaiseksi tilanne vaikuttaa olevan sellainen, ettei kaikkien kantilta katsottuna täydellistä turvatalletusjärjestelmää ole olemassa lainkaan.

Miksi turvatallettaminen on tarpeen?

Turvatallettaminen on tarpeen esimerkiksi sellaisissa ympäristöissä, joissa on niin oleellista tietoa, että tarvitaan vakuus siitä, ettei yhden toimijan haluttomuus tai kyvyttömyys toimia yhteystyössä vaaranna tiedon saatavuutta. Lisäksi turvatallettamista käytetään usein rikosten tutkimisen ja ehkäisemisen vuoksi. Tällöin jokin päättävä elin katsoo tarpeelliseksi saada keinon tarkkailla rikoksesta epäiltyjen viestintää, vaikka se olisi ulkopuolisilta salattua. Tällainen oli motivaatio myös NSA:n 'Clipper chip' -projektilla, joka aiheutti voimakkaan vastareaktion yksityisyyden suojaa varjelevien tahojen suunnalta ja oli laatuaan ensimmäinen suurempaa yleisöä koskeva avainten turvatalletusjärjestelmä [2]. Joissain tilanteissa käyttäjä voisi myös itse hyötyä turvatalletuksesta, mikäli hän sattuisi vahingossa hukkaamaan jonkin tärkeän avaimen. Usein tällaisia tilanteita varten varaudutaan kuitenkin muilla keinoilla.

Turvatallettamiseen liittyviä uhkia ja riskejä

Jokainen avainten turvatalletusjärjestelmä sisältää heikkouksia verrattuna järjestelmään ilman turvatalletusta. Ensimmäinen heikkous käyttäjän näkökulmasta liittyy siihen, että on olemassa toinen, käyttäjästä riippumaton reitti selkotekstiin, jonka turvallisuudesta käyttäjä ei tiedä. Toinen useimpia järjestelmiä koskeva heikkous liittyy siihen, että ulkopuolinen tarkkailija tietää salauksesta enemmän turvatalletusjärjestelmässä kuin sellaisessa, johon ei turvatalletusta liity ja saattaa sitä kautta saada helpommin murrettua salauksen. [1]

Yksi suurimmista uhkista liittyy siihen, että mukana järjestelmässä on aina avaimenhaltijan lisäksi vähintään yksi muu ihminen. Käyttäjän onkin luotettava tämän (paremmassa tilanteessa useamman) ihmisen haluttomuuteen ottaa hänen avaintaan tallesta ilman, että sovittu luovutusehto täyttyy. Hyökkääjän näkökulmasta voidaan ajatella, että on ehkä helpompaa kiristää tai hankkia avain kolmannelta osapuolelta, jolla ei ole henkilökohtaisesti välttämättä niin suurta tarvetta suojella tietoa, johon avaimen avulla pääsee käsiksi, kuin varsinaiselta avaimenhaltijalta. [1]

Eräs uhka liittyy puolestaan siihen, että normaalisti istuntokohtaiset avaimet suunnitellaan siten, että vaikka yhden istunnon avain paljastuisi hyökkääjälle, hyökkääjä joutuu näkemään saman vaivan selvittääkseen seuraavan istunnon avaimen, eli yhden avaimen paljastuminen ei vaaranna seuraavien istuntojen tietoturvaa. Ominaisuutta kutsutaan 'forward secrecy':ksi, mutta myöhemmin olen suomentanut sen 'säilyväksi turvallisuudeksi'. Kun on olemassa jokin toinen reitti selkotekstiin, jonka tulee toimia kaikkiin istuntoihin (tässä siis keino, jolla kolmas osapuoli saa kyseisen istuntoavaimen käyttöön), vaarantaa sen paljastuminen mahdollisesti kaikkiin istuntoihin (ellei järjestelmässä ole erikseen varauduttu tällaiseen jotenkin, kuten myöhemmin esitetään). [1]

Turvatalletusjärjestelmiin kohdistuvia vaatimuksia

On siis selvää, että avainten turvatalletuksen implementointi järjestelmään tuottaa uusia tietoturvaongelmia ja sitä kautta paljon töitä sekä implementoinnin yhteydessä, että siinä vaiheessa kun lopullista järjestelmää analysoidaan ja sen toimivuutta testataan. Joissain tapauksissa on mahdollista, että järjestelmä muuttuu turvatalletuksen vuoksi niin monimutkaiseksi, ettei ole enää mielekästä varmistua siitä, että järjestelmä todella toimii halutulla tavalla kaikissa olosuhteissa, vaan tyydytään vain riittävään todennäköisyyteen. Erittäin tärkeää onkin tiedostaa, millainen vaikutus avaimen turvatalletuksella on järjestelmän tietoturvallisuuteen ja siten myös miettiä, mitkä tarkalleen ovat luottamuksellisuuden ja saatavuuden prioriteetit missäkin sovelluksessa. [1]

Avainten turvatalletusjärjestelmään voidaan kohdistaa esimerkiksi sellainen vaatimus, että yhden istuntoavaimen palauttaminen ei saa vaarantaa muiden, myöhempien istuntoavaimien turvallisuutta. Tällainen ominaisuus turvatalletusjärjestelmään on mahdollista saada esimerkiksi palautusavainten aikarajoituksella tai kertakäyttöisyydellä, jolloin samalla palautusavaimella ei ole mahdollista purkaa useampaa kuin yhtä istuntoa. Näin hyökkääjä joutuisi tekemään vähintään saman määrän työtä istuntoavaimen saamiseksi palautusavainta hyväksikäyttämällä, mikäli oletetaan myös, että palautusavain on yhtä hankalaa saada selville kuin itse istuntoavainta.

Varsinkin kaupallisessa maailmassa on mahdollista, ettei käyttäjä halua luovuttaa avaintaan vain yhden tahon haltuun, jolloin järjestelmään on mahdollista sisällyttää vaatimus siitä, että avaimet turvatalletetaan halutulla tavalla esimerkiksi jaettuna salaisuutena usealle taholle niin, ettei kukaan yksittäinen taho pääse yksin käsiksi talletettuihin avaimiin.

Eräs pohdinnan arvoinen seikka sisältyy myös siihen, että normaalin käyttäjän autentikoinnin lisäksi täytyy olla kattava autentikointi myös kolmannella osapuolella, jotta myös turvatalletetut avaimet olisivat oikeasti turvassa. Tämä voi joissain tapauksissa olla jopa ongelmallinen tilanne, jos turvatalletettuihin avaimiin on pääsy suurella joukolla henkilöitä, kuten esimerkiksi kaikilla poliisiviranomaisilla. On luultavasti helpompaa esiintyä jonain suuremman joukon jäsenenä kuin yhtenä tiettynä yksilönä. [1] Lisäksi, mikäli monilla ihmisillä on pääsy turvatalletettuihin avaimiin, lisääntyy todennäköisyys sille, että joku päättää käyttää avaimia ilman oikeita perusteita, kuten seuraavasta esimerkistä huomataan.

Esimerkki: Regulation of Investigatory Powers Act 2000

Iso-Britannian lainsäädännössä on kohta, jonka pohjalta on mahdollista määrätä henkilö luovuttamaan avain salattuun aineistoon. Lyhyesti esitettynä säädös kertoo, että jos viranomainen kohtaa salattua aineistoa ja on vahva epäilys että avain aineistoon on jonkin henkilön tai tahon hallussa, on mahdollista määrätä epäilty avaimenhaltija luovuttamaan avain. Viranomainen saa määrätä avaimen pakkoluovutukseen niissä tapauksissa, kun kansallinen turvallisuus on uhattuna, avainta tarvitaan rikoksen havaitsemista tai ehkäisyä varten tai Iso-Britannian taloudellinen hyvinvointi on vaakalaudalla. [3]

Iso-Britannian käytäntö eroaa muista turvatalletuskäytännöistä ainakin niin, ettei siinä tarvitse tallettaa avaimia talteen etukäteen mihinkään valtion säilöön (eli kyseessä on siis enemmänkin pakkoluovutus kuin turvatalletus), vaan avain velvoitetaan kertomaan, kun viranomainen sitä tarvitsee. Tämä on toisaalta käyttäjän tietoturvan kannalta parempi näin, sillä selkotekstiin ei tälloin varsinaisesti ole toista, täysin hänestä riippumatonta reittiä, mutta toisaalta ilmoille jää ongelma tilanteessa, jolloin käyttäjä pakkoluovutuksen edessä joko oikeasti on unohtanut, tai väittää unohtaneensa salasanansa, jolloin on edessä ikävä juridinen ongelma. Lisäksi on olemassa erilaisia ohjelmia (esim. TrueCrypt?), joilla saa salattua tiedon lisäksi tiedon olemassaolon, jolloin käyttäjä pystyy kieltämään tiedon olemassaolon, eikä sitä muuten ole helppo näyttää toteen.

Kuten aiemmin uhkia käsitellessä pohdittiin, niin myös tässä tapauksessa ihminen on osoittautunut heikoimmaksi lenkiksi, sillä eräs neuvosto Iso-Britanniassa on jo myöntänyt vakoilleensa erästä perhettä kyseiseen säädäntöön vedoten, ilman että luovutusehdot ovat täyttyneet. [4] Tilanne on siltä kantilta ongelmallinen, että tällaista ei oikeastaan voida varsinaisesti estää, sillä rangaistus väärillä perusteilla tehdyistä avaimen haltuunotoista tulee vasta myöhemmin, eikä avaimenhaltija voi mitenkään etukäteen varmistua siitä, että luovutusehto täyttyy, vaan hänen on vain luovutettava avain ellei itse halua rangaistusta.

Päätelmät

Kokonaisuutena voidaan todeta, että avainten turvatalletus vaikeuttaa eri sovellusten toteutusta, syö paljon resursseja implementointivaiheessa sekä heikentää jokaisessa tapauksessa ainakin hieman järjestelmän tietoturvaa verrattuna tilanteeseen missä ei turvatalletusta ole. Lisäksi järjestelmät ovat todella monimutkaisia, jolloin riski muun muassa virheisiin kasvaa. Tästä syystä on todella olennaista huomioida myös nämä seikat turvatalletusjärjestelmää käyttöönottaessa ja pohtia tarkkaan missä järjestelmässä tällainen on oikeasti tarpeen ja hyödyt ovat suuremmat kuin haitat. Kyseessä on siis todellakin kompromissi saatavuuden ja luotettavuuden välillä.

Ideatasolla avainten turvatalletus on hyödyllinen ja hyvä asia niin viranomaisten käytössä kuin kaupallisessa maailmassakin, mutta ongelmien määrä nykyisissä turvatalletustavoissa vaikeuttaa niiden yleistymistä. Väärinkäytösten helppous valtiotasolla toteutetuissa järjestelmissä aiheuttaa närää ihmisissä ja vastaavasti yritysmaailmassa suurin ongelma lienee uudet tietoturvaongelmat, jotka turvatalletusjärjestelmät esittävät. Uusille paremmille turvatalletusmalleille lienee tulevaisuudessa kuitenkin edelleen kysyntää.

Lähteet

[1] The Risks Of "Key Recovery," "Key Escrow," And "Trusted Third-Party" Encryption. Abelson, Hal et al. (viitattu 14.09.2008)

[2] Clipper Chip Data Sheet. NIST.gov - Computer Security Division - Computer Security Resource Center. (viitattu 14.09.2008)

[3] Regulation of Investigatory Powers Act 2000. Office of Public Sector Information. (viitattu 27.10.2008)

[4] Council Spying a Family. BBC News. (viitattu 27.10.2008)

[5] A Proposal for Authenticated Key Recovery System

[6] MASO-aineisto: Key Escrow (viitattu 15.11.2009)
Print version |  PDF  | History: r4 < r3 < r2 < r1 | 
Topic revision: r4 - 16 Nov 2009 - 01:22:02 - HansAhrenberg?
 

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