Luottamusketjuista

Varmennehierarkia

Varmenne on useimmiten osa varmennehierarkiaa, eli katkeamatonta varmenteiden allekirjoitusten ketjua. Varmenteiden myöntäjä liittää tuottamiinsa varmenteisiin tiedon varmentajasta. Vastaavasti varmentajien omat varmenteet ovat ylemmän tason varmentajien allekirjoittamia ja niin edelleen, kunnes päästään nk. juurivarmenteeseen asti. Yksittäisen varmenteen aitouden todistamiseksi käydään lävitse koko sen myöntämiseen liittyvä ketju lävitse alhaalta ylös asti, tarkistaen allekirjoitukset ja varmenteiden voimassaolot. Juurivarmenne poikkeaa alemman tason varmenteista siten, että se on itse allekirjoitettu - eli ei löydy enää tahoa, joka voisi vahvistaa sen aitouden.

Varmennehierarkian etuna on, että välivarmenteiden ja juurivarmenteen kautta kolmannet osapuolet voivat todentaa alempien tason varmenteiden aitouden. Luottamus varmenteen tietoihin perustuu varmenne hierarkiassa mm. olettamukseen siitä, että välivarmentajien sekä juurivarmentajan varmennepolitiikka on luottamuksen arvoinen, toiminta on varmennepolitiikan mukaista, varmentajien tekniset ratkaisut ovat turvallisia, varmenteeseen liittyvät yksityiset avaimet eivät ole vaarantuneet, luotetut varmentajat ovat otettu turvallisesti käyttöön ja varmenteet ovat väitetyn tahon hallussa.

Vaikka edellä mainitut olettamat vaikuttavat haasteellisilta, ne ovat paljon helpompia todentaa hierarkiassa kuin yksittäisten varmenteisiin kuulumattomien varmenteiden osalta. Lisäksi keskitetyn varmentajan suojaaminen on todennäköisesti hajautettuja malleja helpompaa ja kustannustehokkaampaa.

Ristiinvarmentaminen

Joskus halutaan sallia toisen organisaation myöntää varmenteita toisen nimissä. Tällöin voidaan suorittaa nk. ristiinvarmentaminen. Ristiinvarmentamisessa varmenteiden myöntäjä allekirjoittaa toisen organisaation alemman tason varmenteen, jota voidaan käyttää varmenteiden myöntämisessä edelleen. Käytännössä saman varmenteen voi olla allekirjoittanut useampi ylemmän tason varmentaja ja samasta varmenteesta voidaan päästä useampaan juurivarmenteeseen.

Ristiinvarmentamista voidaan hyödyntää organisaatiorajat ylittävässä toimijassa, kun päätetään luottaa toiseen organisaatioon, jonka kanssa ei kuitenkaan haluta tai käytännön syistä voida rakentaa yhteistä varmennehierarkiaa. Tyypillisesti tämä saattaa tulla vastaan esim. toimintoja ulkoistettaessa ja yritysten välistä yhteistyötä rakennettaessa. Lisäksi samalla menetelmällä voidaan organisaatiouudistuksissa alistaa varmenteet uuteen kohtaan varmennehierarkiaa.

Vaikka ristiinvarmentaminen ratkaisee joitakin käytännön ongelmia, sitä pidetään yleisesti erittäin epäsuositeltavana tekniikkana. Ristiinvarmentaminen aiheuttaa pitkällä aikavälillä mm. seuraavanlaisia haasteita:

• luottamusketju voi syntyä kahden pisteen välille useita eri reittejä pitkin
• eri reiteillä voi olla voimassa erilaiset määreet, kuten voimassaoloajat ja varmenteiden käyttörajoitukset
• luottamusketju voi varmennehierarkian muutoksissa hajota
• luottamusketjuun voi syntyä silmukoita
• ohjelmistoja ei ole suunniteltu hallitsemaan esim. ristiinvarmennetun varmenteen aitouden todistamista luotettavasti

Vaihtoehtoisia tapoja

Joskus halutaan minimoida ulkoiset riippuvuudet, mutta käyttää kuitenkin julkisen avaimen salausta. Se on yksinkertaisimmillaan mahdollista tallentamalla tieto luotettujen vastapäiden julkisista avaimista. Vaihtoehtoisesti voidaan luoda itseallekirjoitetut varmenteet ja ristiinvarmentaa ne. Tällöin ei synny monimutkaisempia luottamusketjuja, mutta tietoa luottamuksesta avaimiin voidaan jaella tarvittaessa eteenpäin.

Yksinkertaista ristiinvarmennusta voi käyttää esimerkiksi salatuissa tietoliikenneyhteyksissä. Lisäksi esimerkiksi salattu suosittu sähköpostin salausohjelma PGP (Pretty Good Privacy) ja sen avoimen lähdekoodin versiot tukevat tekniikkaa, jossa osapuolet voivat suorittaa eräänlaisia ristiinvarmennuksia ("avainten allekirjoitus").

Yksinkertainen ristiinvarmennus soveltuu erinomaisesti yksittäisten henkilöiden välisen sanomaliikenteen suojaamiseen, koska silloin ei haluta tyypillisesti luottaa ulkoisiin tahoihin varmentajana. Lisäksi arkaluonteista tietoa halutaan kohtalaisen harvoin vaihtaa ventovieraiden - joita ei ole todennettu esimerkiksi tapaamalla kasvotusten - kanssa. Ristiinvarmentaminen voidaan luontevasti tehdä osana sosiaalisen kontaktin perustamista.

Varmennepolitiikka

Varmennepolitiikkakuvaa varmenteen soveltuvuuden tietyn yhteisön ja/tai sovellusluokan käyttöön huomioiden niiden turvallisuusvaatimukset. Toisin sanoen varmennepolitiikka kuvaa miten varmentaja varmistaa tietoturvallisuutensa, varmenteiden myöntämisen vain valtuutetuille tahoille ja hallinnoi varmenteita luotettavasti.

Varmennepolitiikan sisältö on standardoitu (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, RFC-3647) ja noudattaa kutakuinkin seuraavanlaista rakennetta.

1. Johdanto
1.1 Yleistä
1.2 Tunnistetiedot
1.3 Juurivarmentaja ja <varmenteen> sovellusalueet
1.4 Yhteystiedot
2. Yleiset Ehdot
2.1 Velvollisuudet
2.2 Vastuut
2.3 Taloudellinen vastuu
2.4 Tulkinta ja täytäntöönpano
2.5 Maksut
2.6 Tietojen julkaiseminen ja saatavuus
2.7 Tietoturvatarkastus
2.8 Tietojen julkaiseminen
2.9 Immateriaalioikeudet
3. <Varmenteen> hakijan tunnistaminen
3.1 Rekisteröinti
3.2 Avainparin uusiminen
3.3 Sulkupyynnön tekeminen
4. Toiminnalliset vaatimukset
4.1 <Varmenteen> hakeminen
4.2 <Varmenteen> myöntäminen
4.3 <Varmenteen> vastaanottaminen
4.4 <Varmenteen> voimassaoloaika ja sulkeminen
4.5 Järjestelmän valvonta
4.6 <Varmenteisiin> liittyvien tietojen arkistointi
4.7 Toiminnan jatkumisen hallinta ja poikkeustapausten käsittely
4.8 Juurivarmentajan toiminnan lakkauttaminen
5 Fyysiset, toiminnalliset ja henkilöstöturvallisuuteen liittyvät vaatimukset
6. Tekniset turvajärjestelyt
6.1 Avainparin luominen ja tallettaminen
6.2 Yksityisen avaimen suojaus
6.3 Muut avaintenhallintaan liittyvät seikat
6.4 Tietokoneiden käyttöön ja niihin pääsyyn liittyvät turvallisuusvaatimukset
6.5 Varmennejärjestelmän elinkaaren hallinta
6.6 Tietoverkon turvallisuus
6.7 Turvamoduulin käytön valvonta
7 Varmentajan varmenne ja sulkulistaprofiilit
7.1 Varmentajan varmenteiden tekniset tiedot
7.2 Sulkulistaprofiili
8 Määritysasiakirjojen hallinta
8.1 Määritysten muuttaminen
8.2 Julkaiseminen ja tiedottaminen
8.3 Varmennepolitiikan muutos ja hyväksymismenettely
8.4 Versionhallinta

Varmennepolitiikasta käyvät ilmi mm. seuraavat asiat:

• Minkälainen tarkastusoikeus asiakkaalla on siihen, että varmentaja toimii kuvaamallaan tavalla? Useimmiten tarkastusoikeus on olematon, 3. osapuolet tarkastavat varmentajan toiminnan määräajoin ja raportoivat siitä. Asiakkaat joutuvat tyypillisesti luottamaan tarkastajien antamiin lausuntoihin ja sertifiointeihin, eivätkä pääse suorittamaan omia tarkastuksia.

• Miten varmentaja tunnistaa asiakkaiden henkilöllisyyden ja varmistaa, että näillä on oikeus tilata varmenteita henkilön tai organisaation nimissä? Varmentajat pyrkivät yleensä estämään identiteettivarkaudet, mm. suorittamalla tarkastuksia kansallisiin yritys- ja henkilörekistereihin ja vaatimalla tilauksen yhteydessä vahvaa sähköistä tunnistautumista.

• Tuottaako varmentaja extended validation -varmenteita? EV-varmenteiden tuottamisessa suoritetaan enemmän tarkastuksia, mistä syystä niitä pidetään normaaleja varmenteita luotettavampana. Useat selaimet näyttävät niitä käytettäessä vihreän luottamusta paremmin herättävän osoitepalkin. Ratkaisu on hieman ironinen, koska varmentajan ydintehtävä on tuottaa varmenteita vain oikeille tahoille, mutta nähtävästi on kaivattu mahdollisuutta myydä eri laatuisia varmenteita eri hintatasoilla.

• Miten varmenteiden tuottamisen prosessi etenee, mukaanlukien sen kuluessa tapahtuvat valvontatoimet ja tiedoksiannot? Prosessin täsmällinen määrittely parantaa sen laatua ja auditoitavuutta, kun taas puutteelliset määritykset saattavat kertoa epämääräisestä toiminnasta.

• Mitä ei-tietoteknisiä järjestelyjä varmentaja käyttää toimintansa turvaamiseen? Esimerkkejä järjestelyistä voivat olla henkilöstön turvallisuusselvitykset, kulunvalvontajärjestelmät, toimitilojen vartiointi, turvatilat, hajasäteilyn suojaus, yhteistyöyritysten väliset turvallisuussopimukset, henkilöstön koulutus tai varavoimalaitteistot.

• Miten varmentaja suojaa varmenteiden tuotantoon käytettävät järjestelmät? Yleensä julkisista tietoverkoista vaikuttaminen varmenteiden tuotantoon on estetty käyttämällä erillisiä tietoverkkoja ja laitteistoja (turvamoduuli). Lisäksi kaikki tietotekniset ratkaisuvat ovat kovennettu yleisimpiä hyökkäystyyppejä vastaan ja auditoitu määrävälein kattavasti.

• Minkälaiset varmentajan omat varmenteet ja sulkulistat ovat? Varmentajan varmenteiden kuvaus kertoo mm. mitä kryptografisia algoritmeja varmentaja tukee, käyttääkö varmentaja OCSP:tä, mitä rajoitteita varmenteisiin on asetettu, varmenteiden sekä sulkulistojen voimassaoloajat ja varmennehierarkian täsmällisen rakenteen.

• Miten varmentaja hallinnoi varmennepolitiikkaa ja sen kuvausta? Varmentajan on todennäköisesti tiedotettava muutoksista varmennepolitiikassa kaikille asiakkailleen ja varmistettava, että kaikki muutokset ovat kuvattu kattavasti varmennepolitiikassa, varmentajan toiminnan läpinäkyvyyden varmistamiseksi.

Suurin osa varmenteista tilataan todennäköisesti erityisemmin arvioimatta varmentajan luotettavuutta. Lisäksi asiakkaat pitävät helposti varmentajan suosiota merkkinä luotettavudesta. Vaikka palvelun suosituimmuus saattaakin nostaa todennäköisyyttä sille, että sen turvallisuutta on arvioitu, se ei ole silti laadun tae. Varmentaja kykenee halutessaan esimerkiksi myöntämään kolmansille osapuolille - kuten tiedusteluviranomaisille - varmenteita toisten tunnistetiedoilla tai laiminlyömään kuvaamansa turvallisuusjärjestelyt. Samanaikaisesti varmentajat saattavat menettää suuria rahasummia raportoidessaan ongelmista palvelussaan, mikä saattaa ohjata varmentajan asettamaan brändinsä suojelun asiakkaiden edun edelle.

Varmennepolitiikassa tyypillisesti viitataan varmentajan sijainnin lainsäädäntöön, esimerkiksi mainitsemalla että varmentaja avustaa paikallisia viranomaisia lainmukaisissa tutkintapyynnöissä. Valitettavasti useissa maissa erityisesti tiedusteluviranomaiset voivat tehdä lähes minkä sisältöisiä tahansa pyyntöjä, eikä varmentajalla ole oikeutta kertoa niistä asiakkaille. Varmentajaa voidaan esimerkiksi pyytää tuottamaan lisää varmenteita, joissa on tutkinnan kohteena olevan yrityksen tai yksityishenkilön tunnistetiedot.

Useimpien valtioiden julkinen hallinto on perustanut luottamuksen haasteiden vuoksi oman julkisten avaimien hallintajärjestelmän. Suomessa varmenteita tuottaa Väestörekisterikeskuksen varmennepalvelut, joiden asema perustuu erityislainsäädäntöön. Laki väestitietojärjestelmästä ja Väestörekisterikeskuksen varmennepalveluista (661/2009) sekä laki vahvasta sähköisestä tunnistamisesta ja sähköisistä allekirjoituksista (617/2009) muodostavat Väestörekisterikeskuksen varmennetoiminnan perustan.

Yksityishenkilöiden ja yritysmaailman osalta tilanne on haastava. Murto-osa yksityishenkilöistä ei tiedostaa varmentajien mahdollisen epäluotettavuuden ja kykenee tekemään asialle jotain. Pieni osa yrityksistä todennäköisesti suorittaa varmentajan valinnan huolellisesti mm. perehtymällä varmennepolitiikkaan ja kykenee jossain määrin hallitsemaan varmenteisiin liittyviä riskejä. Loput saavat käyttöönsä luotettavan varmentajan tuottamia varmenteita lähinnä tuurilla, eikä ongelmaan ole toistaiseksi kehitetty toimivaa ratkaisua.

Let's Encrypt-projekti tuottaa varmenteita osittain aatteellisista lähtökohdista ja on saavuttanut suuren suosion erityisesti harrastelijapiireissä. Resurssien vähyys, heikko varmenteiden tilaajien tunnistaminen, kokemuksen puute, heikko lainsäädännöllinen asema ja resurssien epätasapaino verrattuna esimerkiksi kansallisiin tiedustelupalveluihin antavat kuitenkin aiheen epäillä ratkaisun turvallisuutta.

Varmenteiden ja yksityisten avaimien jakelu

Varmenneketjuja voidaan hyödyntää varmenteiden jakeluun, mutta juurivarmenteiden jakeluun liittyy erityisiä ongelmia. Lisäksi yksityisten avainten turvallinen käsittely saattaa joissain tapauksessa vaatia erityisratkaisuja.

Juuri- ja välivarmenteiden jakelu

Luotetun varmenteen aitous voidaan tarkastaa varmentajan varmenteen avulla, varmentajan varmenteen aitous sen varmentajan avulla ja niin edelleen, kunnes saavutaan juurivarmenteeseen asti. Juurivarmentaja on itse allekirjoitettu varmenne, joten ketju katkeaa ja varmenteen aitous on tarkastettava muilla menetelmin. Periaatteessa juurivarmenteesta voidaan laskea tiiviste ja vertailla sitä varmentajalta luotettavalla menetelmällä saatuun tiivisteseen. Esimerkiksi Internetistä ladattu varmenne ja sen tiivisteet saattavat kuitenkin olla samalla epäluotettavalla sivulla - jos siinä on tietoturvallisuusongelma, asiakas ei pysty suojautumaan tilannetta vastaan lähes mitenkään. Miten sitten juurivarmenteeseen voi luottaa?

Käytännössä käyttöjärjestelmien ja selainten toimittajat ovat ottaneet juuri- sekä välivarmenteiden osalta auktoriteetin roolin. Esimerkiksi Microsoft ja RedHat jakelevat osana käyttöjärjestelmiään ja niiden turvallisuuspäivityksiä juuri- sekä välivarmenteita ja asettavat ne automaattisesti luotetuiksi tiettyihin käyttötarkoituksiin. Vastaavasti yritykset voivat jaella järjestelmänhallintatyökaluillaan omat varmenteensa. Varmennehierarkian huipulla onkin juurivarmenteen sijaan käytännössä joko ohjelmistotoimittajat tai järjestelmänhallintatyökalut.

Mielenkiintoista edellisessä on se, että käyttöjärjestelmien ja selainten toimittajat eivät kuvaa toimintaansa varmennepolitiikkaa vastaavalla tasolla, eivätkä organisaatioiden omat IT-osastotkaan sitä usein muista tehdä jaellessaan varmenteita. Lisäksi harrastelijakäyttäjät eivät käytännössä koskaan tarkasta asentamiaan varmenteita, eikä heillä aina siihen olisi edellytyksiäkään.

Todennäköisyys sille, että Internetistä ladattu ja tarkastamaton varmenne ei ole aito, on erittäin alhainen. Todennäköisyys sille, että potentiaalinen hyökkääjä pystyisi samalla ohjaamaan kohteensa liikenteen omiin palveluihinsa, jotka näyttäisivät päällepäin aidoilta, on vielä alhaisempi. Käytännössä se vaatisi jonkin verran taitoa ja resursseja, joten yksityishenkilöt tuskin koskaan ovat kohteina. Yritykset ja julkisen hallinnon organisaatiot saattavat kuitenkin kiinnostaa valtiollisia toimijoita, joilla on resursseja moninkertainen määrä. Varmentajan varmeiden onnistunut vaihtaminen vaarantaa koko varmennehierarkian turvallisuuden täydellisesti (vrt. symmetrisen salausavaimen vaarantuminen).

Yksityisten avaimien jakelu

Yksityiset avaimet tuotetaan yleensä lopullisessa käyttökohteessaan (esim. kohdepalvelimella), josta ne eivät poistu koko elinkaarensa aikana. Yksityisten avaimien on siis tarkoitus säilyä vain ja ainoastaan varmenteen tilaajan tiedossa. Varmentajalle lähetetään allekirjoituspyyntö (Certificate Signing Request, CSR), joka sisältää varmenteen tuottamiseen tarvittavat attribuutit, julkisen avaimen ja yksityisellä avaimella tehdyn allekirjoituksen. Varmentaja vastaa allekirjoituspyyntöön lähettämällä allekirjoitetun lopullisen varmenteen. Sekä allekirjoituspyyntöä, että vastausta voidaan käsitellä ilman erityistä suojaamista.

Tarkalleen ottaen yksityisiä avaimia ei ole pakko tuottaa lopullisessa käyttökohteessaan. Varmenteen tilaaja voi tuottaa tarvittavat yksityiset avaimet ja allekirjoituspyynnöt esimerkiksi verkottomalla työasemalla ja kopioida avaimet varmenteideen käyttökohteisiinsa. Tämä on hyväksyttävä toimintatapa, jos yksityiset avaimet kyetään suojaamaan riittävän hyvin siirron ajaksi. Yksityiset avaimet voidaan suojata esimerkiksi avainsäilöllä, joka suojaa sisältämänsä tiedot vahvalla salasanalla. Avainten tuottaminen keskitetyssä paikassa saattaa yksinkertaistaa tilausprosessia ja olla kokonaisuutena hyvinkin turvallinen ja toimiva käytäntö erityisesti yhden organisaation sisäisessä palvelutoiminnassa.

Myös varmentaja voi tuottaa yksityiset avaimet ja toimittaa ne asiakkaille. Malli on hyvä, jos esimerkiksi halutaan varmistautua yksityisten avainten laadusta keskitetysti. Tällöin vaaditaan erityinen luottamus varmentajan kykyyn käsitellä yksityisiä avaimia sekä ratkaisuun, jolla yksityiset avaimet toimitetaan turvallisesti. Pelkkä avainsäilö ei riitä jälkimmäiseen, vaan myös avainsäilöön liittyvä salasana- tai salausavain täytyy kyetä jakamaan turvallisesti. Esimerkiksi vartiointipalvelun kuljettama paperikuori saattaa olla hyväksyttävä ratkaisu, joskaan ei kovinkaan kustannustehokas.