Markku Kontio
Sähköinen henkilökortti
Diplomi-insinöörin tutkintoa varten tarkastettavaksi jätetty diplomityö.
Työn valvoja: professori Arto Karila
Työn ohjaaja: diplomi-insinööri Markku Sievänen
Espoo 1.6.1999
Tekijä: Markku Kontio
Työn nimi: Sähköinen henkilökortti
Päivämäärä: 1.6.1999 Sivumäärä: 78
Osasto: Tietotekniikan osasto Professuuri: Tik-110
Työn valvoja: professori Arto Karila
Työn ohjaaja: diplomi-insinööri Markku Sievänen
Avoimissa tietoverkoissa tarjottavissa palveluissa on usein tarve todentaa palveluita käyttävä ihminen. Perinteiset todentamismenetelmät (esimerkiksi viranomaisen myöntämä henkilöllisyystodistus) eivät tarjoa mekanismeja todentaa ihmisiä tietoverkoissa, joten tunnistamisen ja todentamisen pitää perustua muihin menetelmiin. Julkisen avaimen infrastruktuuriin ja toimi- korttiteknologiaan perustuva sähköinen henkilökortti on yksi ratkaisumalli kyseiseen todentamisongelmaan. Tämän lisäksi se tarjoaa myös muita tieto- turvapalveluita kuten tiedon luottamuksellisuuden, eheyden ja kiistämättömyy
den.
Tässä diplomityössä esitetään mitä toiminnallisia ja turvallisuuteen liittyviä vaatimuksia sähköiselle henkilökortille voidaan asettaa, ja esitetään ratkaisuja näiden vaatimusten toteuttamiseksi toimikortin ja julkisen avaimen infrastruk
tuurin avulla.
Työssä käsitellään sähköiseen henkilökorttiin liittyvää vielä varsin kesken
eräistä standardointitilannetta ja tutkitaan sähköisen henkilökortin turvallisuu
teen liittyviä ongelmia.
Työn osana toteutetaan ohjelmistokomponentti, joka tarjoaa rajapinnan sähköi- sen henkilökortin palveluihin.________________________________________
Avainsanat: toimikortti, tietoturva, kryptografia, julkisen avaimen infrastruktuuri
Author: Markku Kontio
Name of the Electronic Identity Card thesis:
Date: 1.6.1999 Number of pages: 78
Faculty: Faculty of Information Professorship: Tik-110 Technology
Supervisor: Arto Karila, Professor
Instructor: Markku Sievänen, M.Sc.
Client authentication is a basic requirement in most of the services that are available in the Internet. There is a need for an electronic identity card, because traditional authentication procedures (e.g. passport or driver’s licence) do not provide means for authentication in networks. Public key infrastructure and smart card technology can be used to implement an electronic identity card that solves the authentication problem. In addition to that it provides security services like data confidentiality, integrity and non-repudiation.
This thesis describes what kind of functional and security requirements can be set for an electronic identity card and proposes feasible solutions that fulfill these requirements. Issues related to the security and usability of the card are analysed. The properties of international standards related to electronic identity cards are described in detail.
A software component that provides an interface to the mechanisms of an electronic identity card is designed and implemented as a part of this thesis.
Keywords: smart card, information security, cryptography, public key infrastrucutre
Alkusanat
Kiitos professori Arto Karila, tämän työn valvoja, visioistasi, motivoinnista ja ajastasi.
Kiitos diplomi-insinööri Markku Sievänen, tämän työn ohjaaja, tietoturva-alan näke- myksestäsi, kommenteistasi ja teekkareita alentavista vitseistäsi, jotka kaikki siivittivät minua tämän työn tekemisessä.
Kiitos Setec Oy, tämän työn taloudellinen tukija, mahdollisuudesta surffata tietoturva- alan suurimman aallon harjalla.
Kiitos Terhi ja Helmiina, elämäni naiset.
Espoossa 1.6.1999
Markku Kontio
Sisällysluettelo
1. Johdanto...1
2. Sähköinen asiointi... 2
3. Tietoturvapalvelut... 3
3.1. Tiedon luottamuksellisuus... 3
3.2. Tiedon eheys... 4
3.3. Todentaminen... 4
3.4. Kiistämättömyys... 6
3.5. Pääsynvalvonta... 6
3.6. Yhteenveto tietoturvapalveluista...7
4. Mekanismit tietoturvapalveluiden toteuttamiseksi... 9
4.1. Tiivistefunktiot... 9
4.2. Symmetriset salausalgoritmit... 9
4.3. Asymmetriset salausalgoritmit...10
5. Avainhallinto...15
5.1. Avainhallinnon ongelmat... 15
5.2. X.509... 17
5.3. PKIX... 26
5.4. PGP... 27
5.5. SPKI... 27
5.6. Yhteenveto julkisen avaimen infrastruktuureista... 28
6. Toimikortti... 29
6.1. Mikä on toimikortti... 29
6.2. Toimikorttistandardit...30
6.3. Toimikortin käyttöjärjestelmä... 31
6.4. Toimikortin komentorajapinta... 31
6.5. Toimikortin tiedostojärjestelmä...32
6.6. Toimikortin lukijalaite... 34
6.7. Toimikortin tietoturvaominaisuudet... 34
7. Sähköinen henkilökortti... 36
7.1. Yleisiä vaatimuksia... 36
7.2. Objektit ja niiden väliset assosiaatiot... 36
8. Sähköisen henkilökortin tietosisältö... 39
8.1. Motivointi... 39
8.2. SEIS... 41
8.3. SS 614330... 44
8.4. PKCS #15... 45
8.5. DIN N1-17.4... 50
8.6. Muut tietosisältöstandardit...50
8.7. Profilointi... 50
8.8. Korttien hallinnointi...51
8.9. Yhteenveto... 51
9. Sähköisen henkilökortin käyttäminen...52
9.1. PKCS#11... 52
9.2. Microsoft CryptoAPI... 53
9.3. SetEID-komponentti... 54
9.4. Käytännön esimerkkejä...55
9.5. Ongelmia... 57
10. Henkilön Sähköinen Tunnistaminen-hanke... 61
10.1. Taustaa... 61
10.2. Sähköisten henkilökorttien valmistaminen... 61
10.3. Kortin tietosisältö... 63
10.4. Kortin ulkoasu... 63
10.5. Sähköinen asiointi... 63
10.6. Lainsäädäntö... 64
11. SetEID-komponentti...65
11.1. Yleistä... 65
11.2. Komponentin vaatimukset... 65
11.3. Komponentin suunnittelu... 66
11.4. Komponentin toteutus... 70
11.5. SetEID-komponentin käyttäminen... 73
11.6. Lopputuloksen arviointi...74
12. Yhteenveto... 75
13. Lähdeluettelo... 76
Symboli-ja lyhenneluettelo
APDU API ASN.l CA CD COM Cryptoki DF DH DOS DPMI DSA EC EEPROM EF
EID ETSI FDIS FINEID FINUID HST ICC IDE IEC IETF IFD ISO ITSEC KEA KVY LDAP MF MFC OOB PDA
Application Protocol Data Unit Application Programming Interface Abstract Syntax Notation One Certification Authority
Committee Draft
Component Object Model Cryptografic Token Interface Dedicated File
Diffie-Hellman Denial Of Service
DOS Protected Mode Interface Digital Signature Algorithm Elliptic Curve
Electrically Erasable Programmable Read Only Memory Elementary File
Electronic Identity
European Telecommunications Standards Institute Final Draft International Standard
Finnish Electronic Identification Finnish Unique IDentifier
Henkilön Sähköinen Tunnistaminen Integrated Circuit Chip
Interface Description Language
International Electrotechnical Comission Internet Engineering Task Force
Interface Device
International Organization for Standardization Information Technology Security Evaluation Criteria Key Exchange Algorithm
Kortin valmistaja ja yksilöijä
Lightweight Directory Access Protocol Master File
Microsoft Foundation Classes Out Of Band
Personal Digital Assistant
PGP Pretty Good Privacy
PKCS Public Key Cryptography Standards PKI Public Key Infrastructure
POP Proof Of Possession
RA Registration Agent
RAM Random Access Memory
ROM Read Only Memory
RSA Rivest, Shamir, Adlemann
SEIS Secure Electronic Information in Society SGC Server Gated Cryptography
SIS Standardisering i Sverige
SSL Secure Sockets Layer
SPKI Simple Public Key Infrastructure
TCB Trusted Computing Base
TTP Trusted Third Party
UML Unified Modelling Language URL Universal Resource Locator
USB Universal Serial Bus
WTLS Wireless Transport Layer Security Protocol
WWW World Wide Web
Kuvat
Kuva 1. SSL todentaminen...5
Kuva 2. Pankkipalvelun osapuolet...7
Kuva 3. Tiivisteen laskeminen... 9
Kuva 4. Symmetrinen salaus...9
Kuva 5. Asymmetrinen salaus...11
Kuva 6. Salausavainten jakelu...H Kuva 7. Digitaalinen allekirjoitus...12
Kuva 8. Viestin salaaminen hybridimenetelmällä...13
Kuva 9. Viestin digitaalinen allekirjoittaminen tiivistettä käyttäen...13
Kuva 10. X.509-infrastruktuuri...18
Kuva 11. Luottamusmalleja... 23
Kuva 12. PKIX-infrastruktuuri... 26
Kuva 13. Sirukorttien luokittelu... 29
Kuva 14. Toimikortti... 30
Kuva 15. Toimikortin tiedostojärjestelmä...33
Kuva 16. UML-malli kortin objekteista...37
Kuva 17. Esimerkki toimikorttijärjestelmän rajapinnoista... 40
Kuva 18. SEIS SI vl-tiedostorakenne... 41
Kuva 19. UML-malli SEIS SI vl objekteista... 42
Kuva 20. SEIS S1 v2-tiedostorakenne... 43
Kuva 21. UML-malli SEIS SI v2 objekteista... 43
Kuva 22. SS 614330-tiedostorakenne... 44
Kuva 23. UML-malli SS 614330 objekteista... 45
Kuva 24. PKCS#15-tiedostorakenne... 46
Kuva 25. PKCS#15 ASN.l-tyyppien perintä... 47
Kuva 26. Erilaisia Cryptoki-toteutuksia...52
Kuva 27. CryptoAPI-arkkitehtuuri...54
Kuva 28. SetCSP ja SSL-todentaminen...55
Kuva 29. PKCS#15-objektien käyttäminen...59
Kuva 30. HST-korttien valmistaminen...61
Kuva 31. UML-kaavio SetEID-komponentin COM-rajapinnoista... 67
Kuva 32. Korttiprofiilin konfigurointiesimerkki...71
Kuva 33. SetEID-komponentin käyttöliittymän ikkunoita...72
Kuva 34. Testiohjelman käyttöliittymä...73
Taulukot
Taulukko 1. X.509-varmenteen ekstensiot... 19
Taulukko 2. X.509-sulkulistan ekstensiot... 20
Taulukko 3. Tärkeimmät toimikorttistandardit...30
Taulukko 4. APDU...31
Taulukko 5. ISO 7816-4 komennot...31
Taulukko 6. Tiedostotyypit...33
Taulukko 7. Pääsynvalvontaprimitiivit...33
Taulukko 8. Käsittelyehtojen tiedostotyyppikohtainen merkitys... 34
Taulukko 9. SEIS SI vl tiedostot... 42
Taulukko 10. SEIS SI v2 tiedostot... 43
Taulukko 11. SS 614330 tiedostot... 44
Taulukko 12. PKCS#15 tiedostot... 46
Taulukko 13. Kaikkien PKCS#15 objektien yhteiset attribuutit... 48
Taulukko 14. Kaikkien avainobjektien yhteiset attribuutit... 48
Taulukko 15. HST-kortin avaimet...63
Taulukko 16. IEidCard-rajapinnan metodit... 67
Taulukko 17. IEidCard-rajapinnan attribuutit...67
Taulukko 18. IPrivateKey-rajapinnan metodit... 68
Taulukko 19. IPrivateKey-rajapinnan attribuutit... 68
Taulukko 20. ICertificate-rajapinnan metodit...68
Taulukko 21. ICertificate-rajapinnan attribuutit...68
Taulukko 22. IPins-rajapinnan metodit...69
Taulukko 23. IPins-rajapinnan attribuutit...69
Taulukko 24. Olennaiset C++ luokat ja niiden toteuttamat COM-rajapinnat... 70
Taulukko 25. SetEID-komponentin käyttämät moduulit...73
1. Johdanto
“Internetissä kukaan ei tiedä, että olet koira”, haukahtaa Internetissä surffaava koira toi
selle koiralle eräässä Gary Larsonin pilapiirroksessa. Larson osuu piirroksellaan tärkeän asian ytimeen, sillä koiran kanssa tietoverkon välityksellä kommunikoiva vastapuoli ei todellakaan pysty päättelemään onko vastaanotettu viesti kirjoitettu koiran karvaisten tassujen vai nörtin nakkisormien avulla. Avoimissa tietoverkoissa ei ole käytettävissä samanlaisia vastapuolen todentamismekanismeja kuin fyysisessä maailmassa. Kaikki informaatio liikkuu tietoverkon läpi digitaalisessa muodossa, bitteinä, jonoina ykkösiä ja nollia, jotka ovat pahantahtoisen osapuolen kopioitavissa ja muutettavissa. Nykyisin käytössä olevia henkilöllisyystodistuksia (kuten viranomaisen myöntämä ajokortti tai passi) ei voida muuntaa biteiksi, koska niiden turvallisuus perustuu sellaisiin fyysisiin turvatekijöihin, joille ei ole vastinetta digitaalisessa maailmassa (esimerkiksi turva- painatukset). Sähköinen asiointi avoimissa tietoverkoissa viranomaisten, pankkien tai muiden palveluntarjoajien kanssa vaatii kuitenkin useissa tapauksissa asiakkaan henki
löllisyyden todentamista, joten on olemassa selkeä tarve digitaalisessa maailmassa käy
tettävälle henkilöllisyystodistukselle.
Moderni kryptografia ja toimikorttitekniikka tarjoavat mekanismeja, joiden avulla voi
daan toteuttaa digitaalisen maailman henkilöllisyystodistus, sähköinen henkilökortti.
Tämän työn tavoitteena on esitellä sähköiseen henkilökorttiin liittyviä teknologioita se
kä kuvata tarkemmin itse kortin toimintaa, sisältöä ja standardointitilannetta.
Sähköinen henkilökortti on turvallisen sähköisen asioinnin mahdollistava väline, jonka avulla voidaan muun muassa todentaa vahvasti kortinhaltijan henkilöllisyys, suojata viestien luottamuksellisuus, estää viestien vakuuttamaton muuttaminen sekä tehdä kiis
tämättömiä digitaalisia allekirjoituksia. Sähköiseen asiointiin liittyviä tietoturvapalve
lulta on kuvattu luvussa 3.
Luvussa 4 esitellään kryptograafisia mekanismeja, joilla tieto turvapalvelulta voidaan toteuttaa. Tämän työn kannalta suurin mielenkiinto kohdistuu asymmetrisiin julkisen avaimen salausalgoritmeihin.
Avainhallinto on sovelletun kryptografian vaikein ongelma. Sen haasteita on kuvattu luvussa 5. Samassa luvussa on esitelty erilaisia julkisen avaimen infrastruktuureja, jotka pyrkivät ratkaisemaan avainhallinnon ongelmia.
Luku 6 sisältää lyhyen johdannon toimikorttitekniikan perusteisiin. Luvussa 7 esitellään sähköinen henkilökortti, joka on julkisen avaimen infrastruktuurissa käytettävä toimi
kortti. Kortin tietosisältöön ja standardointitilanteeseen paneudutaan tarkemmin luvussa 8. Sähköisen henkilökortin käyttämiseen liittyviä ohjelmointirajapintoja ja ongelmia kuvataan luvussa 9.
Suomi on maailmassa ensimmäisten joukossa ottamassa käyttöön kansalaisille jaettavaa sähköistä henkilökorttia, joka tulee tarjoamaan pääsyn muun muassa valtionhallinnon palveluihin. Tähän liittyvää Henkilön Sähköinen Tunnistaminen-hankeita esitellään lu
vussa 10.
Tämän työn osana toteutettiin komponenttiteknologiaan perustuva sähköisen henkilö
kortin palveluita tarjoava SetEID-komponentti, jonka suunnittelu, toteutus ja käyttämi
nen on esitetty luvussa 11.
2. Sähköinen asiointi
Sähköisellä asioinnilla tarkoitetaan tässä työssä avoimissa tietoverkoissa tarjottavien palveluiden käyttämistä. Esimerkkinä sähköisestä asioinnista voidaan pitää Internetissä tarjottavia pankkipalveluja tai viranomaispalveluja (veroilmoituksen täyttäminen, muuttoilmoituksen jättäminen). Perinteiseen fyysiseen asiointiin verrattuna sähköisen asioinnin edut ovat palveluntarjoajalle kustannustehokkuus, asiakkaalle palvelun saata
vuuden paraneminen (paikka- ja aikariippumattomasti suoraan kotoa tai työpaikalta 24 tuntia vuorokaudessa).
Mikäli tietoverkoissa tehdään asioita, jotka heijastuvat fyysiseen mailinaan, pitää vas
tuukysymysten selvittämiseksi olla olemassa polku tietoverkon pääteoliosta juridiseen henkilöön. Anonyymi keskustelupiiri voi toimia Internetissä ilman yhtymäkohtia todel
liseen elämään, mutta pankkipalvelun tilisiirrot vaativat käytännössä juridisen henkilön todistettua läsnäoloa. Tässä työssä keskitytään jatkossa nimenomaan oikeustoimikelpoi- sen sähköisen asioinnin vaatimusten täyttämiseen.
Sähköisen asioinnin tietoturvatarpeet ovat sovelluskohtaisia. Joissain palveluissa voi olla olennaista todentaa palveluita käyttävä juridinen henkilö, kun taas toisissa palve
luissa voi olla tärkeintä suojata asiakkaan ja palvelun välinen viestiliikenne ulkopuoli
silta kuuntelijoilta. Sähköisen asioinnin tietoturvatarpeiden analysointi on ensimmäisiä palvelun pystyttämiseen liittyviä tehtäviä. Seuraavassa luvussa esitellään sähköiseen asiointiin liittyviä tietoturvapalveluita ottamatta vielä tarkemmin kantaa niiden toteutuk
seen.
3. Tietoturvapalvelut
Tässä luvussa esitellään lyhyesti seuraavat sähköiseen henkilökorttiin liittyvät tietotur
vapalvelut:
Tiedon luottamuksellisuus Tiedon eheys
Todentaminen - Kiistämättömyys
Pääsynvalvonta
Edellämainitut käsitteet ovat korkean tason palveluita, jotka voidaan toteuttaa usealla eri mekanismilla. Luvussa 4 käydään läpi sähköiseen henkilökorttiin liittyviä tietoturvame- kanismeja.
Erottamalla palvelut ja mekanismit toisistaan selkiytetään tietojärjestelmän turvallisuu
den suunnitteluprosessia. Ensin määritellään järjestelmän objektien vaatimat tietoturva- palvelut ja vasta sen jälkeen syvennytään teknisiin mekanismeihin joilla kyseiset pal
velut toteutetaan.
3.1. Tiedon luottamuksellisuus
Luottamuksellisuuden määritelmän mukaan sellainen tieto, joka on ainoastaan valtuu
tettujen tahojen saatavilla, on luottamuksellista (confidentality). Tiedon luottamukselli
suus on määritelty ISO:n standardissa ISO/IEC 10181-5 [1].
Esimerkkinä voidaan pitää kahdenkeskistä kirjeenvaihtoa, jossa tieto voi olla ulkopuoli
sen (esimerkiksi postinkantaja) hallussa, mutta hän ei pääse käsiksi tiedon sisältöön avaamatta kirjettä. Luottamuksellisuuden toteuttavana mekanismina on tässä tapaukses
sa kirjekuoren tarjoama fyysinen suoja. Analoginen tapaus sähköisestä maailmasta on salattu sähköpostiviesti, joka kulkee ulkopuolisten hallussa olevien solmujen läpi. Täs
säkään tapauksessa ulkopuolinen ei pääse käsiksi viestin sisältöön murtamatta meka
nismina käytettyä salausta.
Yleensä keskitytään estämään luottamuksellisen tiedon semantiikan vuotaminen ulko
puolisille. Tiedon salaaminen on sopiva mekanismi tähän tarkoitukseen, mutta pelkällä sisällön salaamisella ei pystytä estämään kaikkien tiedon attribuuttien vuotamista ulko
puoliselle. Esimerkiksi henkilön A henkilölle В lähettämä sähköpostiviesti paljastaa pelkällä olemassaolollaan ulkopuoliselle, että A:n ja B:n välillä on jonkinlainen suhde.
Samoin viestin koosta ja sen lähetyspäivämäärästä voidaan mahdollisesti päätellä jotain itse viestin sisällöstä. Nämä attribuutit eivät ole merkityksellisiä useimmissa tapauksis
sa, mutta niiden olemassaolo on hyvä tiedostaa.
Seuraavassa listattuna muutamia esimerkkejä mekanismeista, joiden avulla voidaan to
teuttaa tiedon luottamuksellisuus :
Tiedon salaaminen (valtuutettujen tahojen hallussa olevalla avaimella) Pääsynesto (tiedoston käsittelyehdot)
- Tiedon fyysinen suojaaminen (kassakaappi)
3.2. Tiedon eheys
Tässä työssä käytettävän eheyden (integrity) määritelmän mukaan sellainen tieto, jonka muuttaminen tai tuhoaminen on mahdollista vain valtuutetuille tahoille, on eheää. Tie
don eheys on määritelty ISO:n standardissa ISO/IEC 10181-6 [2].
Tiedon eheys yhdistetään yleensä muihin tietoturvapalveluihin, varsinkin tiedon alkupe
rän todentamiseen ja kiistämättömyyteen [3] (tosin eheyden määritelmän mukaan on olemassa valtuutettu taho, joka on eheyden tarkistamisen yhteydessä implisiittisesti to
dennettu).
Käytännön esimerkkinä tiedon eheydestä voidaan pitää lähettäjän sinetillä suljettua kir
jekuorta. Vastaanottaja voi kirjettä avatessaan tarkistaa sinetin ja vakuuttua siitä, että kirjekuoren sisältö (viesti) ei ole muuttunut siirtotien aikana. Sähköisessä maailmassa joudutaan käyttämään kryptograafisia mekanismeja eheyden varmistamiseksi (esimer
kiksi digitaalisia allekirjoituksia tai kryptograafisia tarkistussummia). Tavallinen tar
kistussumma (CRC, henkilötunnuksen viimeinen merkki tai pankkikortin sarjanumeron viimeinen numero) ei toteuta tiedon eheyden määritelmää, koska kyseinen tarkistus
summa on muidenkin kuin valtuutettujen tahojen laskettavissa. Tavallisilla tarkistus
summilla voidaan estää vain tahattomat (esimerkiksi tiedonsiirtohäiriöiden aikaansaa
mat) viestien muutokset.
Tiedon eheys on useissa sovelluksissa tärkeämpää kuin tiedon luottamuksellisuus. Tämä johtuu siitä, että tietojärjestelmissä tehdään erilaisten syötetietojen perusteella operaati
oita, joihin liittyy suuria taloudellisia väärinkäytösmahdollisuuksia, mikäli syötetietoja päästään valtuuttamattomasti muuttamaan.
Tiedon luottamuksellisuus ja eheys ovat keskenään ortogonaalisia tietoturvapalveluja.
Tiedon salaaminen ei varmista tiedon eheyttä, sillä salattua tietoa voidaan muuttaa (to
sin ‘järkevän’ selväkielisen viestin aikaansaaminen tällä tavalla voi olla vaikeaa). Vas
taavasti tiedon eheyden varmistaminen ei millään tavalla suojaa luottamuksellisuutta.
3.3. Todentaminen
Tunnistamisella (identification) tarkoitetaan tässä työssä sellaista toimintoa, jonka tu
loksena syntyy assosiaatio pääteolion ja sen identiteetin välillä (identiteetillä tarkoite
taan tässä yhteydessä niitä ominisuuksia, jotka tekevät oliosta yksilöllisen). Todentami
sella (authentication) tarkoitetaan tässä työssä sellaista toimintoa, jonka avulla voidaan varmistua tunnistamisen tuloksena saadun assosiaation pitävyydestä. Todentaminen on määritelty ISO:n standardissa ISO/IEC 10181-6 [4].
Tunnistaminen ja todentaminen kulkevat siis käsi kädessä, nämä kaksi termiä sekoittu- vatkin usein tavallisessa kielenkäytössä.
Todentaminen jakaantuu kahteen luokkaan:
Vastapuolen todentaminen - Tiedon alkuperän todentaminen
Vastapuolen todentaminen tarkoittaa tietoliikenneyhteyden toisessa päässä olevan pää
teolion todentamista, käytännön esimerkkinä voidaan pitää SSL-yhteyden avaamisen aikana tehtävää palvelimen todentamista. Asiakas voi varmistua sen avulla palvelimen identiteetistä.
Tiedon alkuperän todentamisen avulla voidaan varmistua tieto-olion muodostajan iden
titeetistä o^/me-tyyppisesti.
ISO:n määritelmän mukaan jokaisella identiteetillä on yksikäsitteinen tunniste (identifier), eli nimi. Päättelyketjua nimi => identiteetti ei kuitenkaan voida pitää itses
täänselvänä, sillä nimi on vain jono bittejä, jonka liittäminen identiteettiin eli oikeaan persoonaan ei ole triviaalia. Todentamisprotokollien lopputuloksena onkin yleensä vas
tapuolen nimi, joten assosiaatio nimestä identiteettiin jää loppukäyttäjän tehtäväksi.
IETF:n Simple Public Key /n/ras/rwcrirre-dokumentaatiossa (SPKI) [6] tähän puuttee
seen kiinnitetään erityistä huomiota.
Esimerkkinä nimen ja identiteetin välisen assosiaation ongelmallisuudesta voidaan pitää yleisesti käytössä olevaa WWW-selainohjelmiston tekemää SSL-protokollan mukaista WWW-palvelimen todentamista. Alapuolella olevassa kuvassa (Kuva 1. SSL todenta
minen) on Netscape Communicator WWW-selaimella otettu SSL-yhteys Meritan Inter
net pohjaiseen Solo-palveluun. Selaimen ikkunan vasemmassa alanurkkaan ilmestynyt lukitun lukon kuva kertoo, että SSL-protokolla on käytössä. Selaimen osoiterivillä on palvelimen nimi, johon SSL-yhteys on otettu.
Solo-pankki - Netscape
HBE
3file £dit View fio Communicator
' i
Íi
ЛA
1 4 ft.ti 551
Back Forward Reload Home Search Netscape Print Security Stop яШл
И & Intiani Menage @1 WebMal 1§1 Connecüonsl |§| BoJoumal ÜSmartUpdate g Mktplace ^ 3 Members ij ^ Bookmarks jfc. Legation:|https://solo3.me(ita.li/cghbin/S0L00001 jr] What's Related
Meritj
Tervetuloa SolcÄankkiin
ritJ
iluÄank Palvelimen nimi: solo3.merita.fi
Tutustu Solo-pankkun opetusohjelman avullal Harjoittele!
Käyttämällä asiakasnumeroa 123456 ja tunnusta 1111 voit tutustua Solo-pankkun käytännössä. Näillä tunnuksilla tehdyt harjoitusmaksut ja toimeksiannot eivät välity eteenpäin.
Solo-pankin käyttö on turvallista, sillä tietoliikenne on salattu.
SSL protokolla käytössä
Sopivimmat selaimet:
Netscape 40x, Explorer 4.0x, AmigalBrowse 1.2, iNETtv Sopivumr
■ Netscape
■ © Copyrij
l$fiS-r
1vttäiätunnukset.
Wksià vastauksineen.
© Copyright Merita Pankki
jSOto
Щдр!
> På svenska
► In English
Asiakasnumero
Tunnus
ok|
Istunto 14531635 sivu 1 23 02.1999 16:21:49
I http://home.netscape.com/bookmafk/4J ''■¿s—! á
Kuva 1. SSL todentaminen
SSL-todennuksen tuloksena loppukäyttäjä voi luottaa siihen, että SSL-yhteyden toisessa päässä on selaimen ympäristössä luotetuksi määritellyn CA:n varmentama WWW- palvelin, jonka nimi vastaa selaimen osoiterivillä näkyvän URL-osoitteen domain-osaa.
Assosiaatiota palvelimen nimen (solo3.merita.fi) ja itse palvelun identiteetin (suomalai
sen Merita pankin asiakkailleen tarjoama Solo pankkipalvelu) välillä ei voida protokol
latasolla taata.
Samankaltainen esimerkki on digitaalisesti allekirjoitetun sähköpostin vastaanottami
nen. Lähettäjän tekemä digitaalinen allekirjoitus tarjoaa vastaanottajalle sähköpostin alkuperän todentamismahdollisuuden. Viestin alkuperän todentaminen voidaan tehdä vahvoilla kryptograafisilla mekanismeilla, mutta sen lopputuloksena ei ole viestin lä
hettäjän identiteetti, vaan hänen nimensä (esimerkiksi sähköpostiosoite, X.500-
hakemistonimi). Jälleen kerran päättelyketju nimi => identiteetti jää loppukäyttäjän vastuulle.
3.4. Kiistämättömyys
Kiistämättömyydellä (non-repudiation) tarkoitetaan tässä työssä toimenpidettä, jonka tuloksena syntyy todisteita, joiden avulla voidaan jälkikäteen (esimerkiksi kiistatilan
teessa) todeta tiedon alkuperä tai saada varmuus siitä, että tieto on vastaanotettu. Kiis
tämättömyys on määritelty ISO:n standardissa ISO/IEC 10181-4 [7].
Kiistämättömyys jakaantuu siis kahteen luokkaan:
- Tiedon alkuperän kiistämättömyys Tiedon vastaanoton kiistämättömyys
Kiistämättömyyden lopputuloksena saadaan digitaalista materiaalia, jota voidaan käyt
tää todisteena tapahtuneesta. Mikäli kyseisen todistusaineiston autenttisuuteen ei voida luottaa, voi teon tekijä kiistää tekonsa. Näin ollen todistusaineiston muodostavan tieto
järjestelmän jokainen komponentti on altis hyökkäyksille.
SPKI-dokumentaatiossa argumentoidaan kiistämättömyyden olevan mahdotonta nykyi
sin yleisesti käytössä olevilla tietojärjestelmillä, joiden luotettu ydin (Trusted Compu
ting Base, TCB) on liian laaja. Vahvemman kiistämättömyyden saavuttamiseksi tarvi
taankin Troijan hevosilta ja muilta hyökkäyksiltä suojattu kiistämättömyysmateriaalin muodostamisjärjestelmä. Näytöllä ja näppäimistöllä (tai vastaavalla syöttövälineellä) varustetut PDA-laitteet [8] sekä GSM-puhelimet [9] ovat hyviä vaihtoehtoja tällaiseksi järjestelmäksi. Mikäli turvallisten laitteiden käyttäminen on vapaaehtoista, voi teon te
kijä kuitenkin aina väittää toimineensa jossain vaiheessa turvattomassa ympäristössä (jossa virheellinen kiistämättömyysmateriaali on väärinkäytöksen seurauksena luotu), joten kiistämättömyysmateriaaliin luottavan tahon asema ei parane vapaaehtoisuuden
ansiosta.
3.5. Pääsynvalvonta
Pääsynvalvoimalla (access control) tarkoitetaan järjestelmän resurssien käytön valvon
taa. Pääsynvalvonta on määritelty ISO:n standardissa ISO/IEC 10181-3 [10].
Valtuutuksella (authorization) annetaan jollekin taholle oikeus toimia valtuutuksessa määrätyllä tavalla. Perinteinen mekanismi oikeuksien myöntämiseen on käyttää pääsyn- valvontalistoja (Access Control List, ACT), jotka kertovat järjestelmän käyttäjien oike
uksista käsitellä järjestelmän objekteja (esimerkiksi tiedostoja). Keskitetysti hallinnoita
viin pääsynvalvontalistoihin on yleensä sisäänleivottuna käyttäjän todentaminen, jonka perusteella päästään käsiksi hänen oikeuksiinsa. Mikäli käyttäjän todentaminen tapahtuu vahvasti ja pääsynvalvontalista kuvaa tarkasti kyseisen henkilön todellisia oikeuksia käyttää järjestelmän objekteja, voidaan järjestelyä pitää hyvänä. Keskitetyn pääsynval- vontalistan ylläpitäminen ei kuitenkaan ole laajassa mittakaavassa yksinkertaista, sillä mikäli käyttäjätunnuksen assosioiminen henkilöön epäonnistuu, menevät myönnetyt oikeudet väärälle käyttäjälle (vertaa todentamisen ongelmat).
SPKI-dokumentaation yksi pääteemoista on valtuutuksen erottaminen identiteetistä.
Yleensä palveluntarjoajan kannalta asiakkaan identiteetillä ei olekaan merkitystä, sillä olennaisempaa on onko kyseisellä asiakkaalla oikeus käyttää kyseistä palvelua. Val
tuutuksen myöntämisen yhteydessä identiteetin tarkistaminen saattaa olla tarpeellista, mutta ei enää palvelun käyttämisen yhteydessä.
3.6. Yhteenveto tietoturvapalveluista
Edellämainitut tietoturvapalvelut tarjoavat perustan turvalliselle sähköiselle asioinnille.
Tarjottavan palvelun luonteesta riippuu mitä tietoturvapalveluita sen toteuttamiseen vaaditaan.
Sähköinen henkilökortti tarjoaa kryptograafisia mekanismeja tietoturvapalveluiden to
teuttamiseen yhdessä henkilökorttia hyväksikäyttävän tietojärjestelmän kanssa. Krypto- graafisista mekanismeista enemmän luvussa 4.
3.6.1. Esimerkki Internet-pohjaisesta pankkipalvelusta
Tässä kappaleessa käydään esimerkinomaisesti läpi Intemet-pohjaisen pankkipalvelun keskeisiä tietoturvatarpeita. Palvelussa on mukana kaksi osapuolta, pankki ja asiakas, joilla molemmilla on omat vaatimuksensa palvelun turvallisuudelle.
Asiakas Pankki
Kuva 2. Pankkipalvelun osapuolet
Seuraavissa kappaleissa on analysoitu tietoturvatarpeita sekä pankin että asiakkaan kan
nalta.
3.6.1.1. Pankin tarpeet
Pankin kannalta on olennaista todentaa asiakas, jotta ulkopuoliset tahot eivät pääse käyttämään pankkipalvelua. Tähän liittyy läheisesti pääsynvalvonta eli se, miten asiakas voi käyttää kyseistä järjestelmää.
Transaktion eheys ja kiistämättömyys on pankin kannalta arvokasta. Mikäli asiakas väittää, ettei ole tehnyt riitelyn kohteena olevaa tilisiirtoa, voi pankki esittää kiistämä
töntä todistusaineistoa tapahtuneesta.
Pankkipalvelun toimintojen luottamuksellisuus ei ole pankin kannalta kaikkein kes
keisintä.
3.6.1.2. Asiakkaan tarpeet
Asiakkaalla on tarve todentaa pankkijärjestelmä, jotta ulkopuolinen taho ei voi pystyttää väärennettyä järjestelmää.
Tehtyjen transaktioiden (esimerkiksi tilisiirto) eheys on asiakkaan kannalta olennaista, sillä väärä kohdetilin numero tai liian suuri summa koituvat asiakkaan tappioksi.
Transaktion vastaanoton kiistämättömyydestä on hyötyä asiakkaalle siksi, että kiistä- mättömyysmateriaalin avulla asiakas voi osoittaa tehneensä esimerkiksi tilisiirron, mi
käli pankkijärjestelmä on toiminut sisäisesti väärin.
Luottamuksellisuus voi olla tärkeää asiakkaalle, kyseessä on kuitenkin varsin subjektii
vinen tarve.
3.6.1.3. Yhteenveto
Edellisten kappaleiden perusteella voidaan huomata, että tietoturvatarpeet ovat jossain määrin erilaisia asiakkaan ja pankin näkökulmista katsottuna. Ehdottoman tärkeinä tie
toturvapalveluina voidaan pitää asiakkaan todentamista ja siihen perustuvaa pääsynval- vontaa, sekä transaktioiden eheyttä.
SSL-protokolla mahdollistaa pankin ja asiakkaan todentamisen, sekä suojaa koko tieto
liikenneyhteyden eheyden. Kaupan päälle saadaa yhteyden luottamuksellisuus, riippuen tosin SSL-protokollan toteutuksen rajoituksista (yleensä rajoittavana tekijänä ovat Yh
dysvaltojen vientirajoitukset vahvalle salaukselle). Nykyisissä Internet pankkipalveluis
sa SSL-protokollaa ei yleensä käytetä asiakkaan todentamiseen, sen sijaan käytössä on perinteinen käyttäjätunnus-salasana menetelmä. Yksi syy tähän on se, että suurimmalla osalla asiakkaista ei ole todentamiseen tarvittavia välineitä.
Transaktion kiistämättömyyttä ei SSL-protokolla pysty takaamaan.
4. Mekanismit tietoturvapalveluiden toteuttamiseksi
Tässä luvussa esitellään lyhyesti sähköiseen henkilökorttiin liittyviä kryptograafisia mekanismeja.
4.1. Tiivistefunktiot
Tiivisteellä (hash) tarkoitetaan digitaalisesta informaatiosta muodostettua kompaktin kokoista sormenjälkeä (yleensä 128 tai 160 bittiä). Tiivisteen muodostamiseen käyte
tään yksisuuntaista tiivistealgoritmia.
Alkuperäinen
digitaalinen viesti Tiivistealgoritmi Tiiviste
Kuva 3. Tiivisteen laskeminen
Tiivistealgoritmien tärkeimpiä ominaisuuksia ovat:
Algoritmi on yksisuuntainen (alkuperäinen viesti => tiiviste), käänteisalgoritmin löytäminen (tiiviste => alkuperäinen viesti) ei ole mahdollista
Algoritmi on törmäysvapaa, eli kahden viestin M ja M’ löytäminen joille pätee H(M) = H(M’) on vaikeaa (H( ) tarkoittaa tiivistefunktion laskemista)
- Algoritmi on tehokas laskea suurellekin tietomäärälle
Tiivisteitä käytetään yleensä digitaalisten allekirjoitusten yhteydessä, tavallisina tarkis
tussummina sekä kryptograafisina tarkistussummina (tiiviste lasketaan viestistä ja jae
tusta salaisuudesta).
Tunnetuimpia tiivistealgoritmeja ovat MD5 (128 bittinen tiiviste) ja SHA-1 (160 bitti
nen tiiviste). Näistä MD5 on vanhempi, yleisempi ja turvattomampi.
4.2. Symmetriset salausalgoritmit
Salausalgoritmin avulla voidaan muuntaa selväkielinen viesti salattuun muotoon. Sala
uksen purkualgoritmilla salattu viesti saadaan palautettua takaisin selväkieliseen muo
toonsa. Symmetrisissä algoritmeissa sekä salaus- että purkualgoritmit käyttävät samaa salaista avainta (secret key). Symmetrisen salauksen periaate on esitetty alla.
Kuva 4. Symmetrinen salaus
Alkuperäisen selväkielisen viestin muodostaminen pelkän salatun viestin perusteella on mahdollista vain sellaisille tahoille, jotka tietävät käytetyn salausavaimen (ja algorit
min). Näin ollen salatun viestin turvallisuus redusoituu avaimen luottamuksellisuuden ja pääsynvalvoiman suojaamiseen, mikäli käytetty algoritmi ei ole murrettavissa. Sa
lausalgoritmit ovat yleensä julkisia, niiden turvallisuutta analysoidaankin laajalla rinta
malla.
Sellainenkin salausalgoritmi, joka ei sisällä heikkouksia, voidaan murtaa brute force- menetelmällä käymällä yksitellen läpi kaikki mahdolliset salausavaimet. Jotta kyseinen hyökkäys voidaan estää, täytyy avainavaruuden olla liian suuri läpikäytäväksi - eli avaimen pituus on ratkaisevassa roolissa. Nykyään pidetään turvallisena yli sata bittis
ten avainten käyttämistä (esimerkiksi 3DES-algoritmi). Turvallinen avainpituus ei kui
tenkaan ole luonnonvakio, sillä tietokoneiden laskentakapasiteetin kasvaminen ja algo
ritmien kryptoanalyysi aiheuttavat koko ajan painetta yhä pidempien avainten käyttöön.
Symmetriset salausalgoritmit ovat erittäin tehokkaita, joten ne soveltuvat hyvin suurten tietomassojen luottamuksellisuuden suojaamiseen. Suurimmaksi käytännön ongelmaksi symmetrisissä salausjärjestelmissä muodostuu avainten jakelu, koska:
Salausavainten luottamuksellisuus pitää suojata
Jaettavien salausavainten määrä kasvaa suureksi, jos on tarpeen kommunikoida kahdenkeskisesti (mikäli osapuolten lukumäärä on n, pitää jakaa —Ц-—- salaista avainta)
Symmetristen avainten jakelun yksinkertaistamiseksi on olemassa luotettuun kolman
teen osapuoleen perustuvia menetelmiä, joista tunnetuin on Kerberos [11].
Symmetrisiä salausalgoritmeja voidaan käyttää luottamuksellisuuden lisäksi tiedon eheyden varmistamiseen. Tämä voidaan tehdä laskemalla ketjutetun symmetrisen sa
lausalgoritmin ja salaisen avaimen avulla viestille kryptograafinen tarkistussumma {Message Authentication Code, MAC), joka lähetetään vastaanottajalle viestin mukana.
Vastaanottaja pystyy jaetun salaisuuden (eli salaisen avaimen) perusteella tarkastamaan tarkistussumman pitävyyden ja voi näin vakuuttua viestin eheydestä. Tämä on yleisesti käytetty menetelmä symmetrisiin algoritmeihin perustuvien maksujärjestelmien trans
aktioiden suojaamiseen.
Symmetrisiä salausalgoritmeja voidaan käyttää seuraavien tietoturvapalveluiden toteut
tamiseen:
Luottamuksellisuus (mekanismina salaus)
- Eheys (mekanismina kyrptograafinen tarkistussumma)
- Todentaminen (mekanismina kryptograafinen tarkistussumma tai salaus)
Kiistämättömyyden saavuttaminen symmetrisiä algoritmejä käyttämällä ei ole mahdol
lista, koska sekä kiistämättömyysmateriaalin muodostaja että kiistämättömyysmateriaa- lin tarkastaja joutuvat jakamaan saman salaisen avaimen. Tästä seuraa se, ettei ulko
puolinen taho voi päätellä kumpi näistä kahdesta muodosti kyseisen materiaalin.
4.3. Asymmetriset salausalgoritmit
Asymmetrisissä salausalgoritmeissa käytetään kahta salausavainta, toista salaukseen (julkinen avain, public key) ja toista salauksen purkamiseen (salainen avain, private key). Asymmetrisiä algoritmejä kutsutaankin usein julkisen avaimen algoritmeiksi. Täs
sä työssä keskitytään jatkossa asymmetrisiin algoritmeihin.
Englanninkielessä symmetrisiä salaisia avaimia kutsutaan termillä secret key ja asym
metrisiä salaisia avaimia termillä private key. Koska suomen kielessä ei ole vastaavia vakiintuneita termejä, käytetään tässä työssä sekaantumisenkin uhalla molemmista avaintyypeistä samaa termiä salainen avain.
Asymmetrisen salauksen periaate on esitetty alla olevassa kuvassa.
Kuva 5. Asymmetrinen salaus
Jotta julkisella avaimella salattu viesti pystytään purkamaan salaisella avaimella täytyy näiden kahden avaimen (avainpari) olla matemaattisesti yhteydessä toisiinsa. Julkisen avaimen perusteella ei kuitenkaan voi päätellä salaista avainta, ellei pysty ratkaisemaan jotain yleisesti vaikeana pidettyä matemaattista ongelmaa. Esimerkiksi 1024 bittisen RSA-avaimen tapauksessa tällainen ongelma on ison luvun (kokoluokkaa 21024 » 10 ) jakaminen alkulukutekijöihin.
Julkinen avain on siis nimensä mukaisesti julkinen, joten sen luottamuksellisuutta ei tarvitse suojata. Tämä on asymmetristen salausjärjestelmien perusperiaate, josta seuraa avainten jakelun helpottuminen verrattuna symmetrisiin salausjärjestelmiin. Avainten lukumäärä pysyy kahdenkeskisessä kommunikoinnissa rajallisena, sillä jaettavien jul
kisten avainten lukumäärä on suoraan verrannollinen kommunikoivien osapuolten lu
kumäärään. Alapuolella (Kuva 6. Salausavainten jakelu) on esimerkki kuuden ihmisen kahdenkeskisen luottamuksellisen kommunikoinnin vaatimasta salausavainten jakelus
ta. Symmetrisessä salausjärjestelmässä jaettavia avaimia on 15, kun asymmetrisessä ta
pauksessa pitää jakaa vain kunkin henkilön julkinen avain.
В
Symmetriset avaimet (15 kpl):
* Kab K\c Rad Rae Rap
* KBC KBD KBE KBF
* Rcd Rce Rcf
* Kde Rdf
•KpF
Julkiset avaimet (6 kpl):
* Pa Pb Pc Pq Pe Pp
D
Kuva 6. Salausavainten jakelu
Jotkut asymmetriset salausalgoritmit (esimerkiksi RS A) toimivat myös käänteisesti, eli salaisella avaimella salattu viesti on mahdollista purkaa julkisella avaimella. Luotta
muksellisuutta ei kyseisellä mekanismilla saavuteta, mutta sen avulla voidaan tehdä di
gitaalisia allekirjoituksia.
Digitaalisen allekirjoituksen periaate on esitetty alla olevassa kuvassa.
Kuva 7. Digitaalinen allekirjoitus
Digitaalisen allekirjoituksen tärkeimpiä ominaisuuksia ovat:
Digitaalisen allekirjoituksen tekeminen on mahdollista vain sellaisille tahoille, joilla on hallussaan salainen avain
- Digitaalisen allekirjoituksen tarkistaminen onnistuu julkisen avaimen avulla
- Digitaalinen allekirjoitus määrittelee tarkasti allekirjoitettavan kokonaisuuden G on
ka muuttaminen jälkikäteen ei ole mahdollista)
Digitaalista allekirjoitusta voidaan käyttää mekanismina eheys-, todentamis- ja kiistä- mättömyyspalveluiden toteuttamisessa.
Tässä työssä käytetään seuraavanlaista notaatiota asymmetristen algoritmien peruspri- mitiiveistä:
- Ea(M) = C, viestin M salaus A:n julkisella avaimella (encrypt)
- Da(C) = M, salatun viestin C purkaminen A:n salaisella avaimella {decrypt)
Sa(M) = C, viestin M allekirjoittaminen A:n salaisella avaimella {sign)
- Va(C) = M, allekirjoituksen C tarkistaminen A:n julkisella avaimella {verify) Asymmetristen algoritmien heikkoutena (verrattuna symmetrisiin algoritmeihin) voi
daan pitää seuraavia seikkoja:
- Asymmetriset algoritmit ovat useita kertaluokkia hitaampia kuin symmetriset algo
ritmit (noin 1000 kertaa hitaampia)
Salattavan lohkon koko on suuri (asymmetrisellä RSA-algoritmilla 1024 bittistä avainta käytettäessä lohkon koko on 1024 bittiä, kun symmetrisellä 3DES- algoritmilla lohkon koko on 64 bittiä), joten pienen datamäärän salattu muoto voi olla alkuperäisen datan kokoon nähden huomattavan suuri
Näiden heikkouksien vuoksi suurten tietomassojen salaukseen käytetäänkin yleisesti hybridimenetelmää, joka yhdistää symmetristen ja asymmetristen algoritmien hyödyt.
Hybridimenetelmässä {Kuva 8. Viestin salaaminen hybridimenetelmällä) itse viesti sa
lataan symmetrisellä algoritmilla käyttäen (pseudo)satunnaista avainta. Salatun viestin perään liitetään vastaanottajan julkisella avaimella salattu symmetrinen salausavain.
Hybridimenetelmän tärkeimmät edut ovat seuraavia:
Suuret viestit voidaan salata tehokkaalla symmetrisellä algoritmilla käyttäen (pseu- do)satunnaista salausavainta
- Sama viesti voidaan lähettää usealle vastaanottajalle salaamalla itse viesti vain kertaalleen, ja liittämällä viestiin jokaisen vastaanottajan julkisella avaimella sa
lattu symmetrinen salausavain
• A muodostaa viestin M
• A generoi satunnaisen symmetrisen salausavaimen R
• A s ai aa viestin M symmetrisellä avaimella R
• Er(M)
• A sai aa B:n julkisella avaimella symmetrisen avaimen R
• EB(R)
• A lähettää B:lle viestin:
• (Er(M), Eb(R)}
(ЩМ), EB(R)}
1
• В purkaa symmetrisen salausavaimen R omalla salaisella avaimellaan
•DB(EB(R)) = R
• В purkaa viestin salauksen symmetrisellä avaimella R
•Dr(Er(M)) = M
Kuva 8. Viestin salaaminen hybridimenetelmällä
Asymmetristen algoritmien hitaudesta johtuen suurten tietomäärien digitaalinen alle- kiijoittamien on hidasta. Tämä pullonkaula pystytään kiertämään käyttämällä tiiviste- funktioita, joiden avulla muodostetaan allekirjoitettavasta viestistä eräänlainen sormen
jälki. Digitaalisen allekirjoituksen yhteydessä ei allekirjoitetakaan itse viestiä, vaan pelkkä sormenjälki. Tiivistefunktioiden ominaisuuksien ansiosta tästä ei aiheudu tieto- turvaongelmia. Tiivisteen avulla tehtävä digitaalinen allekirjoitus on esitetty alla olevas
sa kuvassa.
• A muodostaa viestin M
• A laskee tiivisteen h viestistä M
• H(M) = h
• A sai aa tiivisteen omalla salaisella avaimellaan
• SA(h)
•A lähettää B:lle alkuperäisen viestin ja salatun tiivisteen:
• {M, SA(h)}
{M, SA(h»
1
В
i
• В laskee viestistä M tiivisteen h’
• H(M) = h’
• В purkaa A:n tekemän allekirjoituksen A:n julkisella avaimella
" VA(SA(h)) = h
•B vertaa keskenään tiivisteitä h ja h’
• h = h’ => allekirjoitus oikein
• h h’ => allekirjoitus ei päde
Kuva 9. Viestin digitaalinen allekirjoittaminen tiivistettä käyttäen
4.3.1. Yhteenveto asymmetrisistä algoritmeista
Eniten käytettyjä asymmetrisiä algoritmeja ovat RS A, DSA ja Diffie-Hellman. Kaikki asymmetriset algoritmit eivät toimi molempiin suuntiin, esimerkiksi DSA-algoritmin avulla pystytään tekemään digitaalisia allekirjoituksia, mutta tiedon salaaminen ei ole mahdollista.
Asymmetrisiä algoritmejä voidaan käyttää seuraavissa tietoturvapalveluissa:
- Luottamuksellisuus Todentaminen Eheys
Kiistämättömyys
Seuraavissa kappaleissa esitetään esimerkkejä näiden palveluiden toteuttamisesta.
4.3.1.1. Luottamuksellisuus
Tiedon luottamuksellisuus saadaan aikaan salaamalla tieto esimerkiksi hybridimenetel- mällä (Kuva 8. Viestin salaaminen hybridimenetelmällä). Salauksen purkaminen on mahdollista vain vastaanottajan salaisen avaimen avulla.
4.3.1.2. Eheys
Tiedon eheys pystytään varmistamaan allekirjoittamalla tieto digitaalisesti (Kuva 9.
Viestin digitaalinen allekirjoittaminen tiivistettä käyttäen). Allekirjoituksen tarkistami
seen käytetään allekirjoittajan julkista avainta. Mikäli viestiä on muutettu (valtuutta- mattomasti) allekirjoittamisen jälkeen, ei allekirjoitus enää päde.
4.3.1.3. Todentaminen
Pääteolion todentaminen voidaan tehdä digitaalisten allekirjoitusten avulla haaste-vaste menetelmällä. Ensin todentaja muodostaa satunnaisen haasteen ja lähettää sen toden
nettavalle, joka allekirjoittaa haasteen digitaalisesti ja palauttaa sen. Todentaja voi tar
kistaa haasteen allekirjoituksen todennettavan julkisen avaimen avulla. Vain julkista avainta vastaavan salaisen avaimen haltija on voinut allekirjoittaa haasteen.
Todentamiseen voidaan käyttää myös salausmekanismia. Ensin todentaja muodostaa satunnaisen haasteen, salaa sen todennettavan julkisella avaimella ja lähettää sen toden
nettavalle. Todennettava purkaa haasteen salauksen omalla salaisella avaimellaan ja lä
hettää alkuperäisen haasteen (tai haasteen tiivisteen) todentajalle, joka voi verrata alku
peräistä haastetta ja saamaansa vastetta. Vain salaisen avaimen haltija on voinut purkaa haasteen salauksen ja pystyy esittämään sen selväkielisenä.
4.3.1.4. Kiistämättömyys
Tiedon alkuperän kiistämättömyys saadaan aikaan viestin lähettäjän digitaalisen alle
kirjoituksen avulla. Vastaanoton kiistämättömyydessä joudutaan yleensä turvautumaan kolmannen osapuolen palveluun.
5. Avainhallinto
Edellä kuvattujen tietoturvapa!veluiden ja mekanismien avulla voidaan toteuttaa turval
lisia sähköisiä asioimispalveluja turvattomassa tietoverkossa. Annetut esimerkit viestien luottamuksellisuuden suojaamista, pääteolioiden todentamisesta ja kiistämättömyyspal- veluista voidaan toteuttaa Internetistä imuroitavissa olevien tunnettujen salausalgoritmi
en ja protokollien lähdekoodien avulla. Kaikki annetut esimerkit sisältävät kuitenkin oletuksen, että avainhallinto on järjestetty turvallisella tavalla. Avainhallinto on kuiten
kin sovelletun kryptografian kaikkein haastavin ongelma.
Avainhallinnon olennaiset kysymykset julkisen avaimen salausjärjestelmissä ovat:
Miten suojaudutaan salaisten avainten vakuuttamatonta käyttöä vastaan?
- Miten hoidetaan käyttäjien julkisten avainten jakelu?
Seuraavissa kappaleissa esitellään avainten jakeluun liittyviä ongelmia, sekä tärkeimpiä julkisen avaimen infrastruktuureja {Public Key Infrastructure, PKI), jotka pyrkivät rat
kaisemaan näitä ongelmia:
- X.509 - PKIX - PGP - SPKI
5.1. Avainhallinnon ongelmat
Todentaminen, luottamuksellisuus ja muut tietoturvapalvelut perustuvat salaisen avai
men käytön suojaamiseen. Julkisella avaimella salattaessa tai allekirjoitusta tarkistetta
essa luotetaan siihen, että salaisen avaimen käyttö on mahdollista vain avaimen lailli
selle omistajalle. Mikäli joku vakuuttamaton taho pääsee käsiksi salaiseen avaimeen (joko sen luohamuksellisuuden tai pääsynvalvoiman pekäessä), pystyy tämä taho te
keytymään avaimen lailliseksi omistajaksi. Tarvitaan siis menetelmiä, jotka suojaavat salaista avainta valtuukamattomalta käytöltä.
5.1.1. Salaisen avaimen luottamuksellisuus
Mikäli salainen avain on missään vaiheessa selväkielisessä muodossa sitä käyttävän työaseman muistissa, on sen luohamuksellisuuden suojaus yhtä vahva (tai heikko) kuin työaseman käyttöjärjestelmän muistiavaruuden suojaus. Yleisesti käytössä olevien käyttöjärjestelmien turvallisuus ei ole riittävä sellaisten avainten säilömiseen, jotka mahdollistavat arvokaan merkittävien toimintojen tekemisen. Ilmeinen ratkaisu on tal
lettaa salainen avainmateriaali loogisesti ja fyysisesti suojattuun evaluoitavissa olevaan erilliseen komponenttiin. Toimikortti {smart card) tarjoaa erinomaisen säilöntäpaikan käyttäjän salaisille avaimille, koska se on fyysisesti suojattu ja sen sisäinen käyttöjär
jestelmä suojaa avaimia loogisella tasolla. Toimikortin ominaisuuksia käydään tarkem
min läpi luvussa 6.
5.1.2. Salaisen avaimen pääsynvalvonta
Salaisen avaimen luottamuksellisuuden suojaaminen ei riitä, sillä mikäli salaisen avai
men pääsynvalvonnasta ei ole pidetty huolta, voi vakuuttamaton taho päästä käyttämään avainta itse avaimen paljastumatta. Hyvänä esimerkkinä tällaisestä uhasta on toimikor-
tin käyttäminen siten, että toimikortin sisältämän salaisen avaimen käsittelyehdot salli
vat avaimen käytön ilman käyttäjän todentamista. Tälläisessä tapauksessa Troijan hevo
nen voi käyttää työaseman kortinlukijalaitteeseen työnnettyä toimikorttia ja sen salaista avainta valtuuttamattomasti, mutta silti itse avain säilyy paljastumatta. Toimikortille talletettujen salaisten avainten käsittelyehdot asetetaankin yleensä siten, että salaisen avaimen operaatioita voi tehdä vasta sen jälkeen, kun kortti on todentanut käyttäjän (normaalisti tunnusluvun avulla). Tämäkään ei kuitenkaan suojaa käyttäjää kaikilta hyökkäyksiltä, sillä käyttäjän syöttämän tunnusluvun tarkistamisen jälkeen kortti voi jäädä huolimattomalta sovellusohjelmalta sellaiseen tilaan, että kortin salainen avain on
Troijan hevosen käytettävissä.
Mikäli julkisen avaimen mekanismeilla toteutettavia tietoturvapalveluita on enemmän kuin yksi, joudutaan harkitsemaan useamman kuin yhden avainparin käyttämistä. Esi
merkkinä tästä voidaan pitää kiistämättömyyden ja todentamisen toteuttamista yhden avainparin avulla. Koska molemmissa palveluissa käytetään mekanismina samalla avaimella tehtävää digitaalista allekirjoitusta, ei salaisen avaimen pääsynvalvonnalla voida erottaa näitä kahta allekirjoitustoimintoa toisistaan. Täten loppukäyttäjällä ei ole todellista kontrollia siihen kumpaa toimintoa ollaan tekemässä - käyttäjä voi luulla te
kevänsä digitaalista allekirjoitusta todentamisen yhteydessä, kun hän itse asiassa alle- kirjoittaakin digitaalisesti velkakirjan. Samankaltainen hyökkäys voidaan tehdä mikäli käytetään huonosti suunniteltua todentamisprotokollaa, jossa palvelin voi allekirjoitut- taa asiakkaalla satunnaisen haasteen sijasta epämieluisan dokumentin tiivisteen.
Tällä hetkellä yleinen mielipide on, että tarvitaan vähintään kaksi avainparia, joista toista käytetään pelkästään kiistämättömyyspalveluun ja toista muihin palveluihin. Täl
löin kiistämättömyysavaimen pääsynvalvontaa voidaan tarkentaa siten, että sen käyttä
minen vaatii aina avaimen haltijan tietoisen hyväksynnän (esimerkiksi eräänlaisen ker- takäyttötunnusluvun syöttämistä). Tämä on kompromissi järjestelmän turvallisuuden ja käytettävyyden välillä. Kolmenkin avainparin käyttämistä on esitetty, tällöin käytettäi
siin omia avainpareja todentamiseen, luottamuksellisuuteen ja kiistämättömyyteen.
Vahvin argumentti kolmen avainparin käytölle on se, että se sallii yritysmaailmassa tar
peelliset salatun tiedon palautusmenettelyt (niin sanottu key recovery luottamukselli- suusavaimelle) vaarantamatta kuitenkaan muita tietoturvapalveluja (yrityksen valtuut
tama taho pääsee käsiksi yrityksen työntekijän salaamaan sähköpostiin, mutta ei voi teeskennellä olevansa kyseinen työntekijä).
5.1.3. Avainten generointi
Avainparien generoinnin yhteydessä pitää varmistua avainten yksikäsitteisyydestä, eli kahdella käyttäjällä ei saa olla samaa avainta (muuten toinen käyttäjä voi tekeytyä toi
seksi). Mikäli avainparien generointi perustuu hyviin satunnaislukuihin ja tarpeeksi pit
kiin avaimiin, voidaan duplikaattien syntymistä pitää erittäin epätodennäköisenä. Mikäli duplikaatteja kuitenkin syntyy, pitää kyseiset avaimet laittaa käyttökieltoon.
5.1.4. Julkisten avainten jakelu
Koska julkiset avaimet ovat nimensä mukaisia julkisia, vaikuttaa niiden jakelu ensisil
mäyksellä triviaalilta. Sitä se ei kuitenkaan ole, sillä julkisten avainten eheys ja omistaja pitää varmistaa. Seuraavassa yksinkertainen esimerkki eheyden suojaamisen tärkeydes
tä. Salausmekanismien esittelyn yhteydessä oletettiin, että sähköpostin lähettäjällä on hallussaan vastaanottajan julkinen avain, jonka avulla lähetettävä sähköpostiviesti on helppo salata ja tällä tapaa suojata viestin luottamuksellisuus. Mikäli joku vihamielinen taho on päässyt vaihtamaan lähettäjän hallussa olevan vastaanottajan julkisen avaimen omakseen, salaa lähettäjä tietämättään luottamuksellisen viestin hyökkääjän julkisella
avaimella. Hyökkääjä voi tämän jälkeen kaapata viestin turvattomasta tietoverkosta ja purkaa salauksen omalla salaisella avaimellaan ja saada näin selville viestin sisällön.
Kaiken lisäksi hyökkääjä voi vielä salata viestin vastaanottajan oikealla julkisella avaimella ja lähettää sen eteenpäin - kukaan ei huomaa mitä tapahtui (man-in-the- тии/d/e-hyökkäys).
Viestin lähettäjän pitää siis varmistua siitä, että hänen hallussaan oleva vastaanottajan julkinen avain on eheä. Avaimen eheyden suojaaminen voidaan tehdä allekirjoittamalla julkinen avain digitaalisesti. Allekirjoituksen tarkistaminen onnistuu kuitenkin vain vastaavan julkisen avaimen avulla, jonka eheys pitää myöskin varmistaa - kyseessä on muna-kana ongelma. Parhaassakin tapauksessa tarvitaan vähintään yksi julkinen avain, jonka eheyttä ei voida taata julkisen avaimen järjestelmän tarjoamilla keinoilla (esimer
kiksi digitaalisella allekirjoituksella). Tätä luotettua julkista avainta voidaan käyttää kaikkien muiden julkisten avainten eheyden varmistamiseen.
Pelkkien julkisten avainten eheys ei kuitenkaan riitä, ellei julkisen avaimen käyttäjällä ole tietoa kyseisen avainparin haltijan identiteetistä, eli eheys pitää laajentaa kattamaan myös assosiaatiota julkinen avain o identiteetti. SPKI-dokumentaatiossa painotetaan myös julkinen avain <=> valtuutus assosiaation tärkeyttä, eli useiden palveluiden käyttä
misen kannalta identiteetti sellaisenaan ei ole tärkeää, vaan valtuutus tehdä toiminto.
Valtuutuksen myöntämisen yhteydessä identiteetin tarkistamiseen on kuitenkin usein tarvetta.
5.2. X.509
X.509-standardin [12] mukaisen julkisen avaimen infrastruktuurin keskeisiä elementtejä ovat {Kuva 10. X.509-infrastruktuuri):
- Varmentaja {Certification Authority, CA), joka julkaisee varmenteen muodossa olevia julkinen avain <=> nimi assosiaatioita
- Vaimenne, CA:n digitaalisesti allekirjoittama tieto-olio, joka yhdistää julkisen avaimen ja sen omistajan nimen toisiinsa
Sulkulista, CA:n digitaalisesti allekirjoittama tieto-olio, jonka avulla CA voi asettaa muodostamansa varmenteen käyttökieltoon
Hakemistopalvelu, varmenteiden ja sulkulistojen säilöniäpaikka
- Varmennettava, eli CA:n kontekstissa yksikäsitteisesti nimetty varmennuksen koh
de (julkista avainta vastaavan salaisen avaimen haltija)
- Varmenteen käyttäjä, eli taho, joka luottaa CA:n muodostamaan julkinen avain o nimi assosiaatioon.
Ristiinvarmenne, joka on CA:n mekanismi ilmoittaa luottamuksesta toiseen CA:han
Varmentaja, CA
4
Varmentaminen ja sulkulistaus
Varmennettava
Varmenteetja Hakemistopalvelu
Varmenteiden ja sulkulistojen hakeminen
▼
Varmenteen käyttäjä
Kuva 10. X.509-infrastruktuuri
X.509-varmenteista käytetään yleisesti nimitystä identiteettivarmenne. SPKI- dokumentaatiossa argumentoidaan kuitenkin tämän termin käyttämistä vastaan, koska X.509-varmenne ei liitä yhteen julkista avainta ja identiteettiä, vaan julkisen avaimen ja nimen.
Varmenteen eheyden takaava CA:n digitaalinen allekirjoitus voidaan tarkistaa CA:n julkisen avaimen avulla, joka pitää olla varmennetta käyttävän tahon hallussa.
CA:lla täytyy olla keino irtisanoa muodostamansa julkinen avain <=> nimi assosiaatio, koska julkista avainta vastaava salainen avain saattaa paljastua tai varmenteen muut tie
dot (esimerkiksi varmennettavan nimi) voivat muuttua. X.509-maailmassa irtisanomis- mekanismina käytetään CA:n säännöllisesti julkaisemia sulkulistoja. Sulkulistatarkis- tusten tekeminen on aina varmennetta käyttävän tahon vastuulla.
5.2.1. Varmenteen tietosisältö
Vaimenne [12] on ASN.l-syntaksin ([13], [14]) avulla kuvattu digitaalisesti allekirjoi
tettu tieto-olio, jonka olennaisimmat elementit ovat:
- CA:n kontekstissa yksikäsitteinen sarjanumero - Varmenteen muodostaneen CA:n nimi
- Varmenteen voimassaoloaika
- Julkisen avaimen omistajan nimi (varmennettavan hakemistonimi, Distinguished Name, DN)
- Julkinen avain
- Laajennukset, eli ekstensiot, jotka sisältävät varmenteen käyttöön liittyviä lisätie
toja (esimerkiksi julkisen avaimen käyttötarkoitus, avaimen tunniste tai julkista avainta vastaavan salaisen avaimen voimassaoloaika, )
CA:n muodostama varmenteen eheyttä suojaava digitaalinen allekirjoitus
Varmennettavan nimeämiseen käytetään X.500-hakemistonimeä, joka on alunperin suunniteltu olevan globaalisti yksikäsitteinen polku X.SOO-hakemistopuun lehteen. Ny
kyään ei enää pidetä itsestäänselvänä varmennettavan hakemistonimen ja X.500-hake- mistopuun yhteyttä.
Koska varmenteen eheys on suojattu CA:n digitaalisella allekirjoituksella, voidaan niitä säilyttää julkisessa varmennesäilössä. X.509-ratkaisuissa tämä säilö on yleensä X.500- hakemistopalvelu, josta varmenteet ovat haettavissa esimerkiksi LDAP-protokollan avulla [15].
X.509-varmenteessa voi olla ekstensioita, eli laajennuksia, joihin voidaan sijoittaa sel
laista tietoa, jota ei varmenteen peruselementeillä voi ilmaista. Kunkin ekstension olen
naisin sisältö on tavujono, jonka semantiikka riippuu ekstension tyypistä. Jokaista eks- tensiota kohden on määritelty lisäksi sen kriittisyys, joka kertoo miten varmennetta tul
kitsevan sovelluksen pitää toimia ekstensiota käsitellessään. Mikäli sovellus ei tunnista kriittiseksi merkittyä ekstensiota, ei varmenteen käsittelyä saa jatkaa.
Seuraavassa taulukossa on esitelty X.509-standardissa luetellut varmenteen ekstensiot:
Taulukko 1. X.509-varmenteen ekstensiot
Ekstension nimi Käyttötarkoitus
authorityKeyldentifier Kyseisen varmenteen (tai sulkulistan) allekirjoituksen tarkistamiseen käytettävän julkisen avaimen tunniste.
Käytetään avainten erottamiseksi toisistaan, mikäli samalla CA:lla on useampia avainpareja (esimerkiksi CA:n avaimen päivityksen yhtey
dessä).
subjectKeyldentifier Varmennettavan julkisen avaimen tunniste.
Käytetään avainten erottamiseksi toisistaan, mikäli samalla henkilöllä on useampia avainpareja.
keyUsage Varmennetun julkisen avaimen käyttötarkoitus, eli mihin kyseistä avainta voi käyttää. Käyttötarkoitusbitit:
digitalSignature, digitaaliset allekirjoitukset muissa kuin kiis- tämättömyyspalveluissa (esimerkiksi todentaminen)
nonRepudiation, kiistämättömyysmateriaalin tarkistaminen keyEncipherment, avaimen salaaminen (esimerkiksi hybri- disalaus)
dataEncipherment, tavallisen datan salaaminen key Agreement, avainten sopiminen
keyCertSign, varmenteen allekirjoituksen tarkistaminen cRLSign, sulkulistan allekirjoituksen tarkistaminen encipherOnly, avainten sopimisen yhteydessä salaaminen decipherOnly, avainten sopimisen yhteydessä salauksen pur
kaminen
extKeyUsage Ylimääräisiä avainten käyttötarkoituksia, jotka ovat vapaasti määri
teltävissä.
privateKeyU sagePeriod Varmenteessa olevan julkisen avaimen salaisen vastinparin voimas
saoloaika.
certificatePolicies Sisältää yhden tai useampia objektitunnuksia (object identifier), jot
ka identifioivat CA:n toteuttaman varmennepolitiikan.
Varmennepolitiikassa kerrotaan muun muassa millaisilla menettely
tavoilla varmennettavan henkilöllisyys on todennettu, miten salainen avain on suojattu sekä mihin varmennetta voi käyttää.
policyMappings Käytetään ristiinvarmenteissa indikoimaan mitkä ristiinvarmennetta- van CA:n varmennepolitiikoista vastaavat ristiinvarmentavan CA:n varmennepolitiikkoja.
supportedAlgorithms Tarkentaa algoritmien valintaa.
subjectAltName Sisältää vaihtoehtoisia nimiä varmennettavalle erilaisissa formaateis
sa, esimerkiksi varmennettavan sähköpostiosoite (RFC 822 formaa
tissa), IP-osoite tai DN S nimi.
issuerAltName Vastaava kuin subjectAltName, mutta sisältää CA:n vaihtoehtoisia nimiä.
subjectDirectory Attributes Sisältää varmennettavan X.500-hakemistoattribuuttien arvoja.
basicConstraints Sisältää tiedon onko tämän varmenteen kohde (varmennettava) CA vai loppukäyttäjä. Mikäli kyseessä on ristiinvarmenne, voidaan lisäk
si rajoittaa varmennepolussa tätä varmennetta seuraavien ristiinvar- menteiden määrää.
nameConstraints Rajoittaa varmennepolussa tätä varmennetta seuraavien ristiinvar- menteiden nimeämistä.
policyConstraints Rajoittaa varmennepolussa tätä varmennetta seuraavien ristiinvar- m ente iden varmennepolitiikkoja (vaatii pakollisen hyväksytyn var- mennepolitiikkatunnuksen tai kieltää policyMappings-ekstension käytön)
cRLDistributionPoints Sisältää tiedon kyseisen varmenteen mahdollisesti sisältävän sulku- listan jakelupisteestä.
5.2.2. Sulkulistan tietosisältö
Säännöllisin väliajoin julkaistava (esimerkiksi kolme kertaa päivässä, joka toinen päivä tai kerran viikossa) sulkulista on CA:n mekanismi X.509-maailmassa asettaa varmenne käyttökieltoon. Sulkulista [12] on ASN.l-syntaksin avulla määritelty digitaalisesti alle
kirjoitettu tieto-olio, jonka olennaisimmat elementit ovat:
Sulkulistan muodostaneen CA:n nimi Sulkulistan muodostamisaika
Seuraavan sulkulistan suunniteltu muodostamisaika
Käyttökiellossa olevien varmenteiden lista, joka sisältää seuraavat elementit:
Varmenteen sarjanumero - Sulkulistauspäivä
- Varmennekohtaiset sulkulistaekstensiot Sulkulistakohtaiset ekstensiot
CA:n muodostama varmenteen eheyttä suojaava digitaalinen allekirjoitus
X.509-sulkulistassa voi olla ekstensioita, eli laajennuksia, joihin voidaan sijoittaa koko sulkulistaan tai yksittäiseen sulkulistattuun varmenteeseen liittyvää informaatiota. Sul
kulistan ekstensiosta määritellään sen kriittisyys samaan tapaan kuin varmenteen eks- tensioissa. Seuraavassa taulukossa on esitelty X.509-standardissa luetellut sulkulistan ekstensiot:
Taulukko 2. X.509-sulkulistan ekstensiot
Ekstension nimi Käyttötarkoitus
authorityKeyldentifier ks. kappale Varmenteen tietosisältö (sulkulistakohtainen ekstensio) issuerAltName ks. kappale Varmenteen tietosisältö
(sulkulistakohtainen ekstensio)
cRLNumber Sisältää monotonisesti kasvavan järjestysnumeron CA:n muodosta
mille sulkulistoille.
(sulkulistakohtainen ekstensio)
reasonCode Sisältää syyn miksi kyseinen varmenne on sulkulistalla. Syykoodi voi olla jokin seuraavista:
unspecified, määrittelemätön
keyCompromise, varemennettavan salainen avain on paljastu
nut
cACompromise, CA:n salainen avain on paljastunut
affiliationChanged, varmennettavan nimi tai muu varmenteen tieto on muuttunut (salainen avain ei ole paljastunut)
superseded, varmenne on tarpeeton (salainen avain ei ole pal
jastunut)
cessationOfOperation, varmennetta ei enää käytetä (salainen avain ei ole paljastunut)
certificateHold, varmenne on toistaiseksi käyttökiellossa removeFromCRL, käytetään vain delta-sulkulistojen kanssa indikoimaan, että varmemme poistetaan sulkulistalta
(sulkulistan varmennekohtainen ekstensio)
holdlnstructionCode Mikäli reasonCoi/e-ekstensiossa on arvo certificateHold, voidaan tällä ekstensiolla ilmoittaa sovelluksille mitä toimenpiteitä toistaisek
si käyttökiellossa olevalle varmenteella voi tehdä.
(sulkulistan varmennekohtainen ekstensio)
invalidityDate Käytetään ilmoittamaan milloin salainen avain on paljastunut tai varmenne on muuten muuttunut käyttökelvottomaksi. Voi olla aikai
semmin kuin varmenteen sulkulistauspäivä.
(sulkulistan varmennekohtainen ekstensio) issuingDistributionPoint Kertoo sulkulistasta seuraa via tietoja:
Sulkulistan jakelupisteen (cRLDistributionPoint)
Onko sulkulista pelkästään loppukäyttäjä- tai CA-varmenteille Mitä syykoodeja sulkulista sisältää
Sisältääkö sulkulista myös muiden CA:iden sulkulistatietoja (sulkulistakohtainen ekstensio)
certificatelssuer Mikäli sulkulista sisältää muidenkin CA:iden sulkulistainformaatiota, kerrotaan tämän ekstension avulla kyseisen varmenteen CA:n nimi.
(sulkulistan varmennekohtainen ekstensio)
deltaCRLIndicator Kertoo sulkulistan olevan deltasulkulista ja määrittelee tätä vastaavan perussulkulistan järjestysnumeron.
5.2.3. Varmennepolut
Varmennepalveluita tarjoaa jo tällä hetkellä lukuisa joukko yrityksiä, eli ei ole olemassa yhtä globaalia CA:ta, joka on luottamuksen lähtöpiste kaikille käyttäjille. Tästä johtuen varmenteen käyttäjälle tulee todennäköisesti jossain vaiheessa käsiteltäväksi varmenne, jonka myöntäjä ei kuulu hänen luottamiensa CA:iden joukkoon. Tässä tapauksessa var
menteen käyttäjällä ei ole hallussaan tuntemattoman CA:n julkista avainta, joten hän ei voi tarkistaa kyseisen varmenteen allekirjoitusta eikä vakuuttua sen eheydestä.
Tälläisen tilanteen selvittämiseksi on kaksi vaihtoehtoa:
- Käyttäjä hakee tuntemattoman CA:n julkisen avaimen ja tarkistaa sen eheyden esimerkiksi jollain oMt-q/^awZ-mekanismilla
- Joku käyttäjän luottamista CA:ista ristiinvarmentaa tuntemattoman CA:n
