Avaintenhallinta

Avaimia tarvitaan sekä fyysisiin lukkoihin että kryptoalgoritmeihin. Jälkimmäisissä on symmetristen avainten lisäksi olemassa epäsymmetrisiä. Kaikenlaisten avainten tapauksessa on tärkeää, että oikeilla henkilöillä on heidän tarvitsemansa avaimet ja muilla ei. Avaintarpeet vaihtelevat ja avaimille voi myös sattua kaikenlaista katoamisesta kopiointiin. Kaikki tällainen asettaa avaimiin kohdistuvia hallinnollisia vaatimuksia niille, joiden intressinä on suojata tietoja tai fyysisiä paikkoja kyseisten avaimien avulla. On keskeistä huomata, että suurin osa näistä hallinnointitehtävistä ei kuulu lukkosepän eikä kryptografin toimenkuvaan.

Avaintenhallinnan ongelmaa voi ymmärtää ajattelemalla omaa salasanojen hallintaansa—olettaen ettei käytä kaikkiin paikkoihin samaa. Nykyihminen tarvitsee salasanoja niin moneen tarkoitukseen, ettei hän voi muistaa kaikkia salasanoja. Hänen ei pitäisi myöskään tallentaa kaikkia salasanojaan samalle välineelle, jotta ei joutuisi pulaan sen kadottua.

Salasanojen takana on laitteita, prosesseja, palveluita, viestintää ja tietoja. Näiden olioiden välisissä suhteissa puolestaan tarvitaan kryptoavaimia. Useissa tapauksissa jonkin muunkin olion täytyy tuntea sama avain—tai sen pari, jos kryptosysteemi on epäsymmetrinen. Tuo muu olio on usein oman vaikutuspiirin ulkopuolella ja enemmän tai vähemmän luotettu.

Avaintenhallintaan voi liittyä monenlaisia vaiheita, sillä avaimillakin on elinkaari. Toteutuksesta muodostuu omia tietojärjestelmiään.

Tärkeä esimerkki avaintenhallinnan tarpeesta on tallennus muualle kuin omassa hallinnassa oleville laitteille, etenkin nykyään suosituksi tulleeseen “pilveen”. Tallennuksen kohteet ulottuvat perinteisistä konkreettisista tiedostoista verkossa tapahtuneen oman toiminnan tuottamiin jälkiin. Tietojen suojaamiseen, vähintäänkin salaamiseen ja purkamiseen, tarvitaan avaimia. Avaimistakin tulee siis tallennettavia tietoja, ja niiden tallennus voidaan ulkoistaa vastaavasti. Onneksi avainmassaa on paljon vähemmän kuin muuta tietoa ja huolenpito voidaan keskittää niihin. Muutakin huolenpitoa tarvitaan, mutta tiedonhallinnan ytimessä on siis avaintenhallinta.

Avaimen elinkaari

Yksi mahdollisuus kryptografisen avaimen “synnyttämiselle” on generointi. Riittävän entropian takaamiseksi siinä tarvitaan kryptografisesti vahvaa näennäissatunnaisuuden lähdettä tai jopa todellisen satunnaisuuden lähdettä. Avaimia voidaan myös johtaa (derive) jo olemassa olevista avaimista käyttämällä sopivia kryptoalgoritmeja, joista käytetään termiä KDF, key derivation functions. Avaimen synnyttyä sitä on säilytettävä turvallisesti.

Avaimet on yleensä jaeltava (distributed) turvallisesti sinne, missä niitä käytetään. Ilmeinen esimerkki on julkinen avain, mutta tämä on mahdollista vaikka avain olisi symmetrinen. Esimerkiksi toimikortin tai IoT-laitteen tarvitsema avain on voitu generoida laitteen ulkopuolella. Toinen esimerkki on istuntoavain eli yhden viestintäistunnon (tai viestin) suojaava avain, jonka toinen osapuoli muodostaa ja välittää toiselle epäsymmetrisen salauksen avulla.

Avaimen käyttö tarkoittaa tietojen suojaamista jollakin tavalla. Saattaa olla tarpeen asettaa rajoituksia sille, kuinka suurta datamäärää samalla avaimella saa suojata ennen kuin avain on vaihdettava tai päivitettävä. Rajoitus voi tulla käytössä olevasta kryptomenetelmästä. Esimerkiksi TLS-määrityksen uusin versio, TLS 1.3 sisältää suosituksia siitä, kuinka paljon dataa kullakin protokollan AEAD-avaimella voidaan suojata ja nämä riippuvat AEAD:ssa käytetyn järjestelmän turvarajoista. TLS sisältää aliprotokollan avainten päivitykseen. Se mahdollistaa uusien avainten muodostamisen suojatun yhteyden sisällä.

Avaimella suojattavan datamäärän lisäksi avaintenhallinnan täytyy pitää kirjaa avaimen iästä, ja käynnistää uudistaminen sen mukaan. On hyvä käytäntö liittää avaimeen myös käyttötarkoitus mahdollisine lisärajoitteineen. Julkisen avaimen varmenteissa nämä tiedot on koodattu avaimeen. Käytäntö ei rajoitu julkisiin avaimiin, vaan se noudattaa yleistä—ja yleisesti rikottua—avainten eriyttämisen periaatetta, jonka mukaan tiettyä avainta tulisi käyttää vain yhteen tarkoitukseen tai yhdessä algoritmissa.

Avain voidaan joutua peruuttamaan (revoke), jos sen havaitaan vaarantuneen. Tästä on tietysti ilmoitettava avaimeen luottaneille osapuolille.

Avain on ehkä myös arkistoitava, jotta sen suojaamat tiedot voidaan hakea tarvittaessa. Arkistointi tarkoittaa pitkäaikaista suojattua tallennusta. Se voi sisältää avaimen salaamisen muilla avaimilla, jotka itsessään vaativat hallintaa. Lopuksi avaimet tulee poistaa turvallisesti niiden käyttöiän päätyttyä. Tämä voi tarkoittaa tallennusvälineiden fyysistä tuhoamista tai avainten huolellista päällekirjoittamista.

On ilmeistä, että avaimen elinkaari ja siihen liittyvät prosessit on harkittava huolellisesti ja dokumentoitava osana suunnitteluprosessia kaikissa kryptografiaa käyttävissä järjestelmissä.

Avaimet voivat vaarantua monella tavalla. Syitä voivat olla ainakin huono satunnaisuus, turvaton kuljetus käyttöpaikkaan, turvaton säilytys, käytön aikainen sivukanavahyökkäys ja puutteellinen poistaminen. Hyökkäys todennäköisesti kannattaa kohdistaa suoraan avaimiin ja niiden hallintaan niitä käyttävien algoritmien sijaan.

Kysymys 1

Edellä sanottiin, että suurin osa avainten hallinnointitehtävistä ei kuulu kryptografin toimenkuvaan. Tässä on luettelo tekstin mainitsemista avaimen elinkaaren vaiheista. Näiden ympärillä on kaikenlaista aidosti hallinnollista puuhaa, mutta melkein kaikessa kryptografia voi olla apuna. On vain kolme kohtaa, joissa jokin kryptoalgoritmi on välttämätön. Mitkä ne ovat?

generointi

johtaminen

jakelu

käyttö

vaihtaminen

päivittäminen

käyttötarkoituksen vahtiminen

peruuttaminen

arkistointi

poistaminen

Kysymys 2

Vaikka edellä oli jo varsin laaja esittely avaintenhallinnan toimista, kaikkea ei mainittu (vaan täydennetään tässä). Mikä asia näistä oli kuitenkin selvästi esillä?

avaimen etukäteinen pakkoluovutus (key escrow)

avaimen käyttötarkoituksen kontrolli

avaimen palauttaminen varmuuskopiosta

avaimen asettaminen sulkulistalle

Avaimen johtaminen

Avaimen johtaminen (derivation) tarkoittaa uusien avainten luontia yhdestä avaimesta, juuriavaimesta. Tähän käytetään erikoisrakenteisia kryptografisia tiivistefunktioita, joille syötetään avaimen lisäksi yleensä ns. suolabittejä (salt), joilla eri johtamiskerrat saadaan tuottamaan erilaisia avaimia. Syötteenä voi myös olla kierrosmäärä, joka funktion sisällä tehdään. Tällä saadaan aikaan tarvittaessa se, että funktion lasku on riittävän hidasta, ettei edes tuloksen paljastuttua ole kätevää ryhtyä kokeilemaan, mikä olisi ollut syötteenä. Tällaista hidasta funktiota tarvitaan, kun juuriavaimena on salasana (ks. seuraava alaluku) — myös salasanojen tallennuksessa. Kun juuriavain on entrooppinen, KDF:n hitaus ei ole tärkeää eikä toivottavaa.

Edellä mainittu erikoisrakenne voi tarkoittaa KDF-käyttöön rakennettua funktiota, mutta usein kyse on tavallisen hash-funktion soveltamisesta. Näin on erityisesti yleiskäyttöisessä HMAC-pohjaisessa KDF:ssä, eli HKDF:ssä. Yleiskäyttöisyys puolestaan tarkoittaa, että HKDF:n määrittely ottaa huomioon erimittaisia syötteitä ja tarvittavien tulosbittien määriä. Suolakin voidaan tarjoilla tai olla tarjoamatta.

HKDF menee karkeasti ottaen näin: Olkoon H jonkin hash-funktion, esim. SHA-256:n mukainen HMAC eli H:n syöte on avain ja data. Jos J on juuriavain ja s on suola (tai nollajono), lasketaan ensin lähtöavain K = H(s, J). Sen jälkeen muita avaimia poimitaan jonosta K1 | K2 | K3 …:

k₀ = tyhjä

k₁ = H(K, k₀ | 1)

k₂ = H(K, k₁ | 2)

k₃ = H(K, k₂ | 3)

….

HKDF:n ideaa kannattaa verrata siihen, miten lohkosalainta käytetään avainvirran tuottamiseen. Tässä on ikään kuin CTR-moodin ja OFB-moodin yhdistelmä. Kunkin k_i:n syöttö seuraavaan H-laskuun on OFB-moodia ja laskurin 1,2,3,… syöttö on CTR-moodia.

Edellä HKDF:n ensimmäinen askel oli H(s,J), missä suolabitit toimivat HMAC-avaimena ja juuriavain J on dataa. Vaikka s olisi nollajono, se on HMAC-avaimen mittainen, ja J voi olla vapaamittainen. Se voi olla esimerkiksi Diffie-Hellmanin avaintenvaihdon tuloksena oleva suuri kokonaisluku.

KDF:n käyttö helpottaa avainten eriyttämisperiaatteen noudattamista. Esimerkiksi riittää käyttää yhtä symmetristä avainta, ja johtaa siitä kaksi, joita tarvitaan, jotta viestin salaus- ja MAC-avain olisivat erilaiset. Toki AE-skeemat tekevät vastaavan eriyttämisen sisäisesti ja tehokkaammin. Toinen esimerkki on KDF:n käyttö uuden avaimen johtamiseksi jokaiselle salausalgoritmin sovelluskerralle, esim. transaktiolle. Tällöin syötteeksi on syytä liittää jokin transaktiosta johdettu tunniste. HKDF ottaa tämänkin huomioon, sillä tällaiselle datalle on määritelty paikka k_i:n ja laskurin välissä.

Vielä yksi mahdollisuus on johtaa jo johdetuista avaimista uusia, jolloin syntyy avainhierarkia (tai avainpuu). Esimerkiksi pankilla voi olla maksujärjestelmän laajuinen pääsalaisuus, josta johdetaan kunkin kortin salaisuus. Tapahtumakohtaiset avaimet puolestaan johdetaan kortin salaisuudesta. Vastaava hierarkia esiintyy muuten varmenteissa. Kummassakin tapauksessa tällaisessa järjestelmässä pääavaimen tallennus ja käyttö tapahtuvat yleensä erikoislaitteilla.

Kysymys 1

HKDF:n esittely ei ole tarkka, mutta sikäli oikein että se on mahdollinen ja järkevä laskea. Mikä muunnos ei olisi mahdollinen

Suolan s tilalla on tyhjä bittijono.

Suolan s tilalla on jono ykkösiä.

Jos juuriavain J on oikean mittainen, se otetaan sellaisenaan lähtöavaimeksi K.

k₀ = s

Salasanapohjainen avainten johtaminen

Hyvin yleinen käytäntö on johtaa avaimia salasanoista. Salasanapohjaisen KDF:n eli PBKDF:n (password-based KDF) tärkeä ominaisuus on hitaus. Se estää hyökkääjää tekemästä tyhjentäviä hakuja. Hitautta voidaan säätää syöteparametrilla, joka asettaa sisäisten laskentakierrosten määrän. Se voi tarkoittaa esim. kymmeniä tuhansia hash-laskuja. Toinen tärkeä parametri on suola (ks. Avaimen johtaminen). Se on selvätekstinen, kymmenien bittien mittainen satunnainen jono. Kun sellainen on mukana laskussa, samasta salasanasta tulee eri tilanteissa erilainen avain erittäin suurella todennäköisyydellä. Tästä seuraa, että hyökkääjä ei voi käyttää ennalta laskettua taulukkoa, jossa on salasana-arvauksia ja niistä laskettuja PBKDF-arvoja. Ilman suolaa tällaisesta voi paljon funktion laskua nopeammin löytää salasanan, josta tietty PBKDF-arvo on laskettu. Esilaskenta pitäisi moninkertaistaa kattamaan kaikki suola-arvot eikä se ole käytännöllistä.

Vaihtoehto avaimen johtamiselle suoraan salasanasta on käyttää salasanatodennusta avaintenvaihdon protokollassa. Tuloksena on salasana-autentikoitu avaintenvaihto eli PAKE (password authenticated key exchange). Jopa toimikortin PIN-luku voi olla riittävä lähtökohta avainten johtamiselle. Siihen tarkoitukseen kehitelty PAKE-protokolla on nimeltään PACE, password authenticated connection establishment.

Kysymys 1

Poikkeuksena moniin muihin kryptoalgoritmeihin salasanoista avaimia johtavan algoritmin pitäisi olla hidas. Tämä toteutuu

tekemällä ohjelmaan turhia silmukoita.

ajamalla ohjelma hitaalla apuprosessorilla.

tekemällä useita kierroksia, jotka vievät laskua eteenpäin hash-ketjun tavoin.

kysymällä salasana käyttäjältä merkki kerrallaan säädettävin väliajoin.

Kysymys 2

Montako erilaista avainta voi johtaa nelinumeroisesta PIN:stä? (Vain yksi vastaus on oikein. Useamman valinta on teknisesti mahdollinen, jotta kaikki kommentit saadaan näkyviin.)

Ei sellaisesta voi johtaa avaimia kryptografiseen käyttöön, sillä entropia on aivan liian pieni.

Nelinumeroisia lukuja on 9000, joten sen verran mutta ei enempää.

Paljon enemmän kuin 10000, mutta sillä rajoituksella, että niihin on liitetty selväkielinen suola-arvo.

Voidaan kirjoittaa algoritmi, joka ottaa syötteeksi tuollaisen PIN:n ja ennen pitkää tulostaa minkä tahansa halutun bittijonon.

Avaimen luominen

Kun kryptosysteemiin täytyy luoda avain eikä sitä voida johtaa mistään aiemmasta, tarvitaan mahdollisimman aitoja satunnaisbittejä. Niitä voitaisiin hakea elektronisten piirien tai avaruuden kohinasta, tai kvanttiefekteistä. Todennäköisesti joudutaan tyytymään käyttöjärjestelmän tarjoamiin näennäissatunnaisiin bitteihin, joita se on kerännyt ympäristöstään (vrt. kohta Satunnaisten…). Lantinheitto olisi hyvä keino mutta turhan hidas.

Yksi vaihtoehto on käyttää PUF-laitetta, jolle annetut syötteet tuottavat ainutlaatuisia vasteita: laitetta ei pysty kopioimaan niin, että kopio tuottaisi samasta syötteestä saman tuloksen. Nimi PUF tulee sanoista Physical Unclonable Function. PUF-laitteen valmistuksessa tuotetaan satunnaisuutta esim. hiukkasten sirottelulla optiseen komponenttiin. Myös tavalliset mikropiirit tarjoavat PUF-piirteen, josta voidaan kehitellä varsinaisia PUF-laitteita. Signaalien viiveitä ja niiden eroja mittaamalla nimittäin täysin samanlaisetkin mikropiirit osoittautuvat erilaisiksi. PUF-laitetta suunniteltaessa täytyy varmistaa, että mitattavat erot jakautuvat sopivasti ja ettei niitä voi mallintaa ohjelmallisesti. Silti voidaan tarvita merkittävää jälkikäsittelyä virheiden korjaamiseksi ja hyvien satunnaisominaisuuksien tuottamiseksi. Avainten generointia helpompi PUF-sovellus on tietokonelaitteiston yksilöinti luotetussa tietojenkäsittelyssä. PUF soveltuu myös haaste-vaste -autentikointiin.

Kun generoitava avain tulee epäsymmetrisen algoritmin käyttöön, tarvitaan yleensä algebrallisia ominaisuuksia. Voidaan joutua generoimaan useita ehdokkaita tai laskemaan niistä eteenpäin, jotta satunnaislukujen joukosta löytyisi esim. satunnainen alkuluku. Kryptosysteemien määrittely ja toteutus sisältävät yleensä proseduurin tätä varten. Eli itsensä ulkopuolelta kryptosysteemi vaatii vain tavallisen satunnaisbittien lähteen.

Avainten luontia voi olla haasteellista toteuttaa rajoitetuissa ympäristöissä, esim. toimikorteissa. Varsinkin henkilökortteina käytettävissä avainta ei pitäisi luoda kortin ulkopuolella ja syöttää valmiina kortille. Vaikka prosessorit ovat tehostuneet, voi olla houkutus optimoida niiden sisällä toteutettavaa generointiprosessia liikaa turvallisuuden kustannuksella.

Kysymys 1

Kun avaimia luodaan, satunnaisbittien generoinnilla voidaan tavoitella myös algebrallisia ominaisuuksia. Sitä ei kannata tavoitella, että bittien muodostama luku on

alkuluku p, jolle pätee että myös (p-1)/2 on alkuluku.

kahden suuren alkuluvun tulo.

alkuluku p, jolle ei p-2 eikä p+2 ole alkuluku.

kakkosen potenssi miinus jokin toinen kakkosen potenssi.

sopiva elliptisen käyrän yksityiseksi avaimeksi.

Kysymys 2

Mitä yhteistä on lantinheitolla ja PUF-laitteella?

Vaikka olisi sama heittäjä ja sama PUF-syöte, kummankaan tulosta ei voi ennustaa.

Kumpikaan ei tuota suoraan sopivia bittejä kryptoavaimiksi.

Kumpikin on liian hidas kryptografiseen käyttöön.

Kummankin satunnaisominaisuudet perustuvat fysikaalisiin ilmiöihin.

Avaimen säilytys (syventävä)

Kun avaimet on luotu, ne on yleensä tallennettava. Poikkeuksena ovat tapaukset, joissa avaimet voidaan luoda uudestaan käyttäjän syöttämästä salasanasta. Voi myös olla, että avain kapseloidaan saman tien lähetettävään viestiin eikä sitä enää tarvita itse.

Yleensä tallennuspaikka on suojattava, jotta avaimet eivät joudu hyökkääjän ulottuville. Usein ainoan suojan tarjoaa käyttöjärjestelmän pääsynvalvonta yhdistettynä laitteistopohjaiseen muistin osiointiin, jolla eri prosessit pidetään erossa toisistaan. Paikalliset hyökkääjät voivat ohittaa tällaiset suojausmekanismit käyttämällä matalan tason keinoja, jotka hyödyntävät prosessien välillä jaettuja resursseja, esim. välimuistia, kuten kerrotaan krypton haasteiden kohdalla. Iso ongelma tämä on usean käyttäjän ympäristöissä, esim. pilvessä, jossa asiakkaalla on vain vähän hallintaa siihen, mitä muita prosesseja hänen omiensa rinnalla on käynnissä. Ongelma esiintyy myös yhden käyttäjän laskentaympäristöissä, kun otetaan huomioon haittaohjelmien mahdollisuus.

Erityinen haaste syntyy, kun internet-selain joutuu toteuttamaan käyttöjärjestelmän tyyppisiä suojauksia esimerkiksi eri välilehdillään ajettavien koodien kesken. Selainprosessi sisältää kryptografisia toimia, jotka ovat yhteydessä myös www-palvelimen prosesseihin. Heartbleed-tapaus vuonna 2014 oli sellainen, jossa palvelimelle tallennettu yksityinen avain saattoi päätyä hyökkääjän tietoon. Taustalla oli yksinkertainen ohjelmistohaavoittuvuus, joka päästi lukemaan puskurin ohi TLS/DTLS Heartbeat -protokollan OpenSSL-toteutuksessa. Vahva kryptografia oli tässä vailla voimaa.

Kun kryptoavaimia pitää tallentaa muistiin tai ohjelmakoodiin, käytetään usein ohjelmallisia hämäännyttämisen tekniikoita (obfuscation), joilla vaikeutetaan avainten tunnistamista ja lukemista. Vastaavasti on olemassa työkaluja, jotka yrittävät purkaa hämäännytyksen. Tälläkin alalla käydään pitkään jatkunutta kilpavarustelua. Hämäännytyksen käyttö ei rajoitu krypto-ohjelmointiin (IPR:n suojelu tai haittaohjelman piilottelu voi käyttää sitä, mutta yksityisyystekniikkana obfuscation on häviöllistä hämärryttämistä).

Erityiset laitteet ovat vaihtoehto sille, että avaimia säilöttäisiin samassa muistissa kuin tavallistakin dataa. Laitteita tähän löytyy kaikissa koko- ja hintaluokissa. Esimerkiksi toimikortin valmistaminen voi maksaa muutaman sentin, mutta se voi olla hyvin suojattu sekä passiivisilta että tunkeutuvilta hyökkäyksiltä, joilla siihen tallennettuja avaimia havitellaan. Hyvin suunnitellun toimikortin käyttöliittymä rajoittaa tarkoin kortin kanssa kommunikoivan kortinlukijan vuorovaikutusta sen kanssa. Erityisesti mikään komento ei saa korttia lähettämään avaimiaan suoraan pois kortilta. Sen sijaan lukija pystyy vain lähettämään tietoja kortille käsiteltäviksi ja vastaanottamaan sitten kortin tekemien kryptolaskelmien tulokset. Toisin sanoen, lukija voi olla vuorovaikutuksessa kortin salaisuuksien kanssa vain kryptoAPI:n kautta. Toimikortit ovat yleensä melko rajoittuneita kaistanleveydeltään ja laskentakapasiteetiltaan.

Asteikon toisessa päässä ovat HSM-moduulit (Hardware Security Module), joiden hinta voi olla nelinumeroinen. Ne paitsi tarjoavat parempia ominaisuuksia myös ovat usein testattuja korkealla turvatason standardien mukaisesti (esim. NIST FIPS 140 -sarja). HSM:t ovat usein käytössä finanssialalla, ja niitä tarjotaan nyt myös pilviympäristöissä. Kuten toimikortti myös HSM tarjoaa avainten säilytys- ja käyttötoiminnot tarkoin valvotun API:n kautta. Sen kautta HSM:n suojausta voidaan laajentaa muualle tallennettuihin avaimiin. Ideana on yksinkertaisesti salata ne vain HSM:n sisällä pysyvällä avaintensalausavaimella. HSM voidaan pyytää purkamaan salaus, kun avainta tarvitaan. Tietysti tarvitaan myös uusi salaus avaimen kuljetusta varten, jos HSM sijaitsee turvattoman linkin päässä.

Myös luotettujen suoritusympäristöjen tekniikat, eli TPM:t (trusted platform modules) tarjoavat laitteiston tukeman tallennuksen avaimille. Näitä ovat esim. Intel SGX ja ARM Trustzone. Sellaisilla on myös paljon yleisempiä ominaisuuksia. Mobiililaitteissa puolestaan Android- ja iOS-käyttöjärjestelmät tarjoavat vastaavanlaista avainten tallennusta: Android Keystore ja iOS Secure Enclave ovat oleellisesti mini-HSM:iä.

Avaimen kuljetus (syventävä)

Järjestelmän rakenteesta riippuen avaimet saatetaan luoda eri paikassa kuin missä niitä käytetään. Kuriireja tai kuriiripalveluita on digiaikanakin käytetty avainten fyysiseen kuljetukseen, aluksi paperinauhalla ja sittemmin magneettisella tietovälineellä. Samantapainen menetelmä, jota yhä käytetään kuluttajasovelluksissa, esim. langattomissa kotireitittimissä, on yksinkertaisesti tulostaa avain laitteen takaosaan. Tällöin turvallisuus perustuu laitteen hallussaolon fyysiseen turvallisuuteen.

Toinen lähestymistapa on laajalti käytössä matkaviestintä- ja pankkialalla. Symmetriset avaimet sijoitetaan edullisiin turvamoduuleihin, jotka jaetaan asiakkaille, esimerkkeinä puhelimen SIM-kortti ja pankkikortti. Näiden avainten kopioita säilytetään palveluntarjoajan käytössä. Matkaviestinnän tapauksessa paikka on loogisessa verkkokomponentissa AuC (authentication center) ja avainta käytetään SIM-kortin autentikoimiseksi verkolle ja istuntoavainten johtamiseksi. Pankkisovelluksissa korttien symmetriset avaimet on tyypillisesti jo johdettu pääavaimista, joita säilytetään pankin HSM:ssä.

Jos avain on jo paikoillaan, sitä voidaan käyttää uusien avainten kuljettamiseen. Julkisen avaimen salaustekniikan keksimisen myötä avainten kuljetusongelma on voitu muuntaa ongelmaksi, joka on vastaanottajan julkisen avaimen autenttisen kopion kuljettaminen lähettäjälle. Koska avaimen ei tarvitse olla salainen, tämä on helpompi ongelma kuin salaisen avaimen kuljettaminen. Tämä on silti edelleen merkittävä ongelma (vrt. PKI). TLS-protokollan aikaisemmat versiot käyttivät nimenomaan avaimen kuljetusta vastaanottajan julkisella avaimella salattuna. Siitä johdettiin KDF:llä muita tarvittavia avaimia molemmissa päissä. Sittemmin KDF:n juuriavain on muodostettu avaintenvaihtoprotokollalla.

Avaimen päivitys ja jatkosuojaus (syventävä)

Jos kahden osapuolen välistä viestintää suojaava symmetrinen avain paljastuu, kaikkien tällä avaimella salattujen tietojen turvallisuus menetetään. Tämä motivoi avainten säännöllisen päivittämisen. Toinen syy on, että joidenkin järjestelmien, kuten AEAD:n, muodollinen turva-analyysi takaa turvallisuuden vain tiettyyn salatun datan määrään asti.

Symmetristen avainten päivittämiseen on olemassa useita mekanismeja. Yksinkertainen tekniikka on johtaa KDF:llä uusi avain olemassa olevasta. Tästä syntyy avainketju. Ajatuksena on, että jos avain paljastuu jossain vaiheessa, mitään aiempaa avainta ei silti voi palauttaa. Tietysti on mahdollista laskea eteenpäin KDF:n avulla kaikki myöhemmät avaimet, sillä oikeiden osapuoltenkin pitää siihen pystyä. Vanhojen avainten säilyminen turvassa nykyisen avaimen paljastuessa tunnetaan termillä jatkosuojaus (forward secrecy, toisinaan forward security, tai perfect forward security). Termi on helpompi muistaa, kun ajattele asiaa kunkin aiemman avaimen (ja viestin) kannalta. Ne pysyvät jatkossakin turvassa siitä huolimatta, että uusia avaimia vain johdetaan (eikä generoida).

Toinen mahdollisuus symmetrisen avaimen päivitykseen on uusien avainten kuljetus yhdeltä osapuolelta toiselle salattuna jälkimmäisen julkisella avaimella. Jos uhkamalliin kuuluu hyökkääjän kyky murtaa vastaanottajan yksityinen avain, niin menettely ei saavuta jatkosuojausta. Jatkosuojauksen tavoittelu tarkoittaa, että on otettu huomioon hyökkääjän kyky murtaa istuntoavain. Yksityisen avaimen murtokyky ei poikkea tästä mainittavasti, eikä lainkaan jos avaimia pitää luovuttaa esim. viranomaisten vaatimuksesta.

Jatkosuojaus voidaan toteuttaa käyttämällä hetkellistä Diffie-Hellman-avainten vaihtoa, jonka autentikointiin voi käyttää esim. osapuolten allekirjoituksia. Tässä hetkellinen viittaa siihen, että Diffie-Hellman -arvot luodaan erikseen kutakin istuntoavaimen päivitystä varten. Englannin termi on ephemeral, jonka suomennos voisi tässä olla myös katoava, sillä avaintenvaihdosta ei jää jäljelle kuin istuntoavain, jolla ei ole mitään yhteyttä muihin avaimiin. Nytkin hyökkääjä on voinut murtaa osapuolten autentikointiin käytettävät yksityiset avaimet, eikä häntä voi estää toteuttamasta välimieshyökkäystä. Sen avulla hän saa osallistujat sopimaan uusista istuntoavaimista itsensä eikä toistensa kanssa. Myös tulevat avaimet vaarantuvat, mutta aiemmin muodostetut istuntoavaimet pysyvät silti turvassa. Niitä ei voi enää muodostaa uudestaan edes kumpikaan rehellinen osapuoli, ei myöskään yhdessä. On aivan eri asia, onko jompikumpi tallentanut jonkin aiemman viestin selvätekstinä tai arkistoinut huonosti salattuna.

Kuten edellä on jo käynyt ilmi, jatkosuojausta toiseen suuntaan täydentävä suojaus on ongelmallinen. Hyökkääjä on jo “sisällä” ja hallitsee tulevaisuutta. Hetkellinen DH-vaihto auttaisi siihen, kunhan edes yksi vaihto päästäisiin tekemään ilman että hyökkääjä pääsee väliin.

Julkisten avainten hallinta ja julkisen avaimen infrastruktuuri

Julkisten avainten ja identiteettien sidonta varmenteilla

Julkisen avaimen kryptosysteemien keskeinen haaste on siinä, miten julkinen avain voidaan kytkeä siihen olioon (ihmiseen tai koneeseen), jonka hallussa vastaava yksityinen avain on. Yksityisen avaimen omistaja pystyy sitä käyttämällä tietenkin osoittamaan, että tietty julkinen avain on hänen. Tämä kytkentä on matemaattinen ja sitä käytetään mm. olion autentikoinnissa. Ongelma on kuitenkin siinä, että tuon olion identiteetistä ei tällä tavoin saada mitään varmuutta. Tarvitaan lisäksi jokin keino, joka kytkee julkisen avaimen ja luotettavan tiedon siitä, kenellä on vastaava yksityinen avain.

Passissa tai muussa tavanomaisessa henkilötodistuksessa henkilön identiteetti perinteisesti kytketään viranomaisen vakuutuksella häntä ilmentävään kuvaan ja allekirjoitukseen, ja nykyään muuhunkin biometriikkaan. Kun tällaista todistusta käytetään autentikoitumiseen, omaa olemusta (ulkonäköä) ja allekirjoituskykyä käytetään ikään kuin yksityisenä avaimena, jonka todentaa julkinen avain (kuva ja mallisigneeraus).

Julkisen kryptoavaimen sidonta henkilön identiteettiin voitaisiin tehdä aivan samalla tavalla kuin passissa valokuva sidotaan nimeen. Tämä ei olisi kovin hyödyllinen tapa tietoverkossa asioinnin kannalta. Sidonta tehdäänkin kryptografian omin keinoin—yksinkertaisesti allekirjoittamalla digitaalisesti lyhyt dokumentti, joka sisältää molemmat sidottavat tiedot. Tätä allekirjoitettua dokumenttia kutsutaan julkisen avaimen varmenteeksi eli sertifikaatiksi. Sellaisen sisältöä ja rakennetta koskee standardi X.509.

Varmenteen allekirjoitus on likimain ainoa kryptografian piiriin kuuluva asia julkisten avainten sitomisessa henkilöiden tai muiden olioiden kuten palvelimien identiteetteihin. Muu on enimmälti hallinnointia, vaikka sen eri vaiheiden turvaamisessa toki käytetäänkin lisää kryptografiaa. Kokonaisuudesta käytetään nimitystä julkisen avaimen järjestelmä, eli PKI (public key infrastructure). Sellaisen tehtävänä on hallinnoida julkisia avaimia ja niiden varmenteita jonkin organisaation, yhteiskunnan tai sellaisen osan puitteissa. Keskeinen rooli tällaisessa järjestelmässä on varmenteiden myöntäjien luotettavuudella ja sillä, miten laajalti muut heidän allekirjoituksiinsa uskovat. Varmenteen myöntäjiä kutsutaan yleensä vain varmentajiksi, aiemmin usein varmenneviranomaisiksi, englannin termin certificate authority (CA) mukaisesti.

Kaikkien osapuolten pitäisi voida luottaa CA:han, erityisesti siihen, että CA todentaa jokaisen asiakkaansa henkilöllisyyden. Varmentaminen on laajaa liiketoimintaa ja ihmistä tavallisempi kohde ovat palvelimet ja verkkosivustot.

Sivustojen varmenteet ovat keskeinen ja näkyvä esimerkki PKI:stä. Siitä käytetään nimitystä web-PKI. Verkkoselainten toimittajat upottavat ohjelmistoonsa luettelon muutaman sadan juurivarmentajan julkisista avaimista ja päivittävät luetteloa ajoittain ohjelmiston päivitysmekanismillaan, joka puolestaan voi turvautua erilliseen varmennestruktuuriin. Verkkosivustojen omistajat hankkivat varmenteita, joilla sivustojen URL-osoitteet sidotaan niiden julkisiin avaimiinsa. Näitä varmenteita ei usein myönnä juurivarmentaja, vaan jokin alivarmentaja, joka on hankkinut avaimelleen varmenteen juurivarmentajalta. Kun sitten käytetään TLS-protokollaa selaimen ja sivuston välistä suojattua viestintää varten, palvelin lähettää varmenneketjun selaimelle. Ketjun lopussa on kopio palvelimen julkisesta avaimesta, siitä jota TLS kohta soveltaa sivuston autentikointiin. Ennen etenemistä selain tarkastaa tämän avaimen varmenteen (verifioi allekirjoituksen ja URL:n) ja siihen tarvittava julkinen avain identiteetteineen on ketjussa seuraavana. Sen tarkastaminen on samanlainen operaatio, joka voi johtaa ketjun seuraavan avaimen käyttöön tai päättyä siihen, että verifioinnissa käytetty avain jo löytyi selaimen juurivarmentajien listasta.

Web-PKI:n toimintoja ja käytäntöjä hallinnoi CA/Browser Forum (2005–). Luottamuksen edistämiseksi on vuodesta 2007 asti ollut tarjolla laajennetun tarkistuksen varmenteita (EV certificates, extended validation c.). Niitä myöntävän varmentajan pitää läpäistä hyväksymismenettely ja sen pitää tarkistaa (eli validoida) varmenteen hakija tavallista paremmin. Selaimet näyttävät EV-varmenteista tavallista enemmän tietoa selaajalle.

Kysymys 1

Kehen pääasiassa luotat, jos ulkomaalaisen esittämän passin perusteella päättelet, mikä hänen nimensä on? Passin

esittäjään.

tarkastaneisiin rajaviranomaisiin.

valmistajaan.

myöntäneeseen viranomaiseen.

Kysymys 2

Kun yksityisellä avaimella tehtyä allekirjoitusta todennetaan vastaavalla julkisella avaimella, matemaattinen kytkentä varmistaa lähinnä sen, että

allekirjoittajan henkilöllisyys on sama kuin se, joka on kytketty kyseiseen julkiseen avaimeen varmenteen avulla.

allekirjoittaja, kuka hän onkin, on tulkinnut oikein bittijonon, jonka hän on syöttänyt allekirjoitusalgoritmille.

allekirjoittaja omistaa tai on omistanut kyseisen julkisen avaimen.

allekirjoittajalla on ollut hallussaan julkista avainta vastaava yksityinen avain.

Kysymys 3

Julkiselle avaimelle K muodostuu varmenne, kun

jokin luotettu taho laatii digitaalisen allekirjoituksen, joka kytkee toisiinsa K:n ja sitä vastaavan yksityisen avaimen.

on laadittu allekirjoitus, jonka voi todentaa K:ta vastaavalla yksityisellä avaimella ja joka kytkee toisiinsa K:n omistajan identiteetin ja K:n.

vastaavaa yksityistä avainta Y käyttäen lasketaan allekirjoitus K:sta ja Y:stä.

joku muu käyttää yksityistä avaintaan allekirjoitukseen, joka sitoo toisiinsa K:n ja sen omistajan identiteetin.

Kysymys 4

Epäsymmetristen kryptosysteemien avaimiin liittyy keskeisesti termit PKI ja CA. Mistä nämä tulevat?

PKI = 0. Public Key Infrastructure | 1. Public Keys for Internet

CA = 10. Certificate Authentication | 12. Certified Authentication | 14. Certificate Authority

Laske numerot yhteen ja valitse oikea summa:

10

11

12

13

14

15

Kysymys 5

Mikä seuraavista väitteistä on epätosi?

Varmenteiden digitaalinen allekirjoittaminen ei ole välttämätön osa julkisen avaimen järjestelmää.

Julkisen avaimen järjestelmä voi ulottua maan rajojen yli tai se voi rajoittua pelkästään tiettyyn yritykseen.

Varmenneketjun voi muodostaa allekirjoitusten sijasta myös hash-funktioilla kuten lohkoketjun .

Julkisen avaimen infrastruktuurin voi rakentaa yhden varmenneviranomaisen varaan.

Riippuvuus nimeämisestä, varmennetoiminnoista ja ajasta

Julkisen avaimen sitominen tiettyyn toimijaan tarvitsee vakaan ja kontrolloidun nimeämismekanismin ja toimijalla on oltava keinot todistaa varmentajalle, että hän omistaa nimetyn identiteetin. Varmentajan täytyy paitsi vaatia sellaiset todistukset myös verifioida ne ja toimia tulosten mukaisesti, eli myönnettävä varmenteita (vain) oikeille osapuolille. Tämän toteutuminen on luottamuskysymys ja siihen on myös laki- ja sääntelynäkökulma.

Web-PKI:ssä on sattunut lukuisia tapauksia, joissa varmentajat ovat antaneet virheellisiä varmenteita joko siksi, että ne on hakkeroitu (esim. DigiNotar 2011), myöntämisprosessia on hallinnoitu huonosti (esim. TurkTrust 2013) tai maan hallitus on halunnut valvontakeinoja kansalaisiaan kohtaan. Toisissa tapauksissa varmentajan on havaittu suojaavan allekirjoitusavaimiaan puutteellisesti.

Vastauksena kasvavaan määrään tällaisia tapauksia Google käynnisti Certificate Transparency -hankkeen (2013, ks. myös RFC 9162, 2021). Tavoitteena on lokitietojen ja monitoroinnin avulla tallentaa tietoa kaikista julkisesti luotettujen varmentajien myöntämistä varmenteista. Tämän avulla voidaan tunnistaa virheellisesti tai pahantahtoisesti myönnettyjä varmenteita.

Varmenteeseen luottava osapuoli tarvitsee tiedon oikeasta ajasta varmistuakseen siitä, että varmenteeseen koodattu käyttöaika on voimassa. Muutoin hyökkääjä voisi saada vanhentuneella mutta muuten validilla varmenteella uhrin käyttämään julkista avainta, jota vastaavan yksityisen avaimen hyökkääjä on onnistunut murtamaan. Tarkan aikatiedon vaatimusta voi olla vaikea toteuttaa halvoissa tai rajoitetuissa ympäristöissä, esim. IoT-sovelluksissa.

Kysymys 1

Mikä näistä ei johda siihen, että varmenteen saa palvelin tai verkkosivusto, jolle se ei kuuluisi?

varmennepalvelun hakkerointi

tunnettua yritystä kirjoitusasultaan muistuttava nimi

varmentajan toimintamaan hallituksen vaikutus

allekirjoitusavainten joutuminen vääriin käsiin

palvelin allekirjoittaa itse varmenteensa OpenSSL:llä

Riippuvuus varmenteen tilatiedoista (syventävä)

Varmenteeseen luottava osapuoli tarvitsee tiedon varmenteen tilasta eli siitä, onko se edelleen voimassa. Tätä varten varmentajat voivat lähettää säännöllisesti varmenteiden peruutuslistoja (CRL, certificate revocation list) ja sellaisten muutoslistoja. Toinen vaihtoehto on pyytää luottava osapuoli suorittamaan reaaliaikainen tarkistus varmenteen myöntäjältä OCSP-protokollalla (online certificate status protocol). Listan käyttö on protokollaa yksityisempi tapa, mutta siinä tarjoutuu hyökkääjälle aikaikkuna peruutusajan ja CRL-jakelun välillä. Protokollan käyttö tarjoaa ajantasaista tietoa, mutta tarkoittaa, että suurten varmentajien on tarjottava merkittävää kaistanleveyttä ja laskentaa online-pyyntöjen palvelemiseksi.

Www-ympäristössä OCSP:stä on tullut hallitseva menetelmä varmenteiden tilan tarkistamiseen. Tiedonsiirto-ongelmaa vähentää OCSP-“niputus”, jossa varmenteen omistava verkkopalvelin suorittaa CRL-julkaisua tiheämmin oman OCSP-tarkistuksensa ja liittää varmenteen oheen varmentajansa allekirjoitetun vastauksen.

Riippuvuus ohjelmiston ja krypton eheydestä (syventävä)

Luottavan osapuolen ohjelmiston on toimittava oikein, kun se tarkistaa sertifikaattiketjuja. Tämä ei ole triviaalia, kun otetaan huomioon X.509-tietorakenteiden ja sen koodauksen monimutkaisuus. Epäonnistumisia on ollut lukuisia. Hyvin tunnettu tapaus oli Applen “goto fail” vuodelta 2014. Koodirivi goto fail; oli vahingossa toistunut. Ensimmäinen rivi toteutettiin sitä edeltävän if-ehdon mukaisesti mutta jälkimmäinen aina. Kyseessä oli sertifikaatin tarkistuksen virheenkäsittely Applen TLS-toteutuksessa. Tuloksena oli, että kaikki sertifikaattien tarkistukset ohitettiin eli www-palvelimen julkinen avain sai olla aito tai hyökkääjän generoima.

Sertifikaatteja soveltava teollisuus on ollut hidas reagoimaan kryptoanalyysin edistymiseen. SHA-1 on hyvä esimerkki. Ensimmäiset SHA-1 -murrot toteutuivat vuonna 2005. Jo tässä vaiheessa tavanomaista varovaisuuttaan noudattavat kryptografit suosittelivat, että SHA-1 poistetaan käytöstä sovelluksissa, jotka vaativat törmäyskestävyyttä. Vuoden 2005 jälkeen SHA-1:n kryptoanalyysi kehittyi, kunnes vuonna 2017 ensimmäiset julkiset törmäykset esiteltiin. Tätä seurasi vuonna 2019 valitun etuliitteen törmäyshyökkäys, joka uhkasi suoraan SHA-1:n käyttöä varmenteissa. Huolimatta siitä, että suunta oli ollut selvä yli vuosikymmenen ajan, kesti vuoteen 2017, ennen kuin suuret verkkoselaimet lopettivat SHA-1:n hyväksymisen Web PKI -sertifikaateissa. Nykyään SHA-1-varmenteita löytyy edelleen maksujärjestelmistä ja muualta. Näitä ylläpitävät organisaatiot ovat luonnostaan muutoshaluttomia, koska niiden on hallittava monimutkaisia järjestelmiä, joiden on jatkettava toimintaa yli teknologisten muutosten. Niillä ei ole kryptografista ketteryyttä.

Muut julkisten avainten hallinnan lähestymistavat (syventävä)

Hierarkkisen PKI:n vaihtoehto on luottamusverkko (web of trust). Siinä järjestelmän käyttäjät takaavat toistensa julkisten avainten aitouden olennaisesti ristiinvarmentamalla niitä. Se on edelleen pohjana PGP-järjestelmälle (Pretty Good Privacy 1991–) mutta ei ole yleistynyt muissa yhteyksissä. Tällainen järjestelmä asettaa tavallisille käyttäjille merkittäviä käytettävyyshaasteita.

Identiteettipohjainen kryptografia (IBC) tarjoaa teknisesti houkuttelevan vaihtoehdon perinteiselle julkisen avaimen kryptografialle. Luotettu osapuoli TA (trusted authority) johtaa käyttäjien yksityiset avaimet suoraan heidän identiteetistään käyttäen omaa yksityistä pääavaintaan. Etuna on, että julkisia avaimia ei tarvitse jaella. Luottavan osapuolen tarvitsee nyt vain tietää toisen osapuolen identiteetti sekä TA:n julkinen avain. Kaikille sovellusalueille tämä ei käy, koska niissä ei voida luottaa TA:han riittävästi. Se pystyisi väärentämään käyttäjien allekirjoituksia ja purkamaan heille tarkoitettuja salatekstejä. Yritysten tietoturvasovelluksissa tällainen avaimen hallinnollinen escrow-ominaisuus voi olla hyödyllinen. (Key escrow yleisesti tarkoittaa “vara-avaimen” luovutusta kolmannen osapuolen haltuun.)

Palautusta lähetetään...