Jukka Pajulehto
NFC-YHTEYDEN MUODOSTUS TERVEYDENHUOLLON TOIMIKORTTEIHIN
Diplomityö
Informaatioteknologian ja viestinnän tiedekunta
Joulukuu 2021
Jukka Pajulehto: NFC-yhteyden muodostus terveydenhuollon toimikortteihin.
Diplomityö
Tampereen yliopisto
Informaatioteknologian ja viestinnän tiedekunta Joulukuu 2021
Digi- ja väestövirasto päivitti terveydenhuollon toimikorttien sirut uudempaan versioon keväällä 2020. Päivitys sisälsi varmenteiden algoritmien päivityksien lisäksi myös uuden ominaisuuden, NFC-tuen. Uusi NFC-ominaisuus helpottaa DVV:n toimikorttien käyttöä erilaisissa sähköisissä palveluissa, jotka vaativat vahvaa tunnistautumista. eRA-potilastietojärjestelmä on yksi näistä paveluista. Lähes kaikissa uusissa puhelimissa on sisäänrakennettu NFC-antenni, jolloin erilliselle lukijalle ei ole tarvetta kortin lukemista varten. Tämä helpottaa eRA:an kirjautumista erityisesti mobiililaitteissa. Näiden hyötyjen takia Atostek Oy päätti toteuttaa NFC-tuen eRASmartCard-kortinlukijasovellukseensa. eRASmartCard-sovelluksen tehtävänä on hoitaa korttikommunikointi eRA-järjestelmän ja DVV:n toimikorttien välillä. Näin ollen NFC-tuen lisäämiseksi muutokset kohdistuivat eRASmartCard-sovellukseen.
NFC-tuen saavuttamiseksi jokaiseen eRASmartCard-sovelluksen versioon täytyi toteuttaa PACE-protokolla. PACE-protokolla on avaintenvaihto-protokolla, joka mahdollistaa turvallisen kommunikointikanavan muodostamisen kortin ja kortinlukijaohjelmiston välille. Protokollan on kehittänyt German Federal Cyber Authority (BSI) ja saksalaiset käyttävät samaa protokollaa omien henkilökorttiensa langattoman kommunikoinnin suojaamiseen.
eRA potilastietojärjestelmänä käsittelee sensitiivistä dataa. Tämän takia eRA:n tietoturvallisuus täytyy auditoida kolmannen osapuolen toimesta. Auditointi asettaa vaatimuksia toimikorttitunnistautumiseen, vaatien toimikortin pitämistä koko potilastietojärjestelmän käyttösession ajan. Tämä vaatimus kohdistuu myös NFC:n välityksellä yhdistettyihin kortteihin mikä aiheuttaa ongelmia NFC-ominaisuuden käytettävyyden suhteen tunnistautumisessa. Kortin pitäminen NFC-antennin kantamalla koko käyttösession ajan ei ole käytännöllistä mobiililaitteissa.
Näistä ongelmista huolimatta NFC-ominaisuus toteutettiin eRASmartCardiin auditointivaatimuksia noudattaen. Jotta NFC-ominaisuus toimisi vaatimusten mukaisesti, täytyi eRASmartCardiin tehdä mekanismi kortin poissaolon tunnistamiseen PACE-protokollan lisäksi.
Kortin yhteyden tilaa haetaan sekunnin välein. Jos kortti tunnistetaan poistetuksi, annetaan kortille 10 sekuntia aikaa uudelleenyhdistämiseen. Jos uudelleenyhdistäminen epäonnistuu tällä aikavälillä, ilmoitus kortin poistumisesta lähetetään eRAan.
Vaikka auditoinnin vaatimukset aiheuttivat päänvaivaa NFC-ominaisuuden toteutuksessa, projekti onnistui kokonaisvaltaisesti hyvin. NFC-ominaisuus toteutettiin onnistuneesti eRASmartCardin Windows, OSX ja Android versioille. iOS alustalle ominaisuutta ei voitu tehdä auditointivaatimusten mukaisesti sillä iOS:n NFC-ominaisuus ei sovellu pitkiin NFC-sessioihin.
Siitä huolimatta NFC-tuki toteutettiin myös iOS-alustalle piiloitettuna ominaisuutena. Ominaisuus voidaan ottaa käyttöön tulevaisuudessa jos auditointivaatimukset keventyvät. Keskustelut vaatimusten keventämisestä aloitettiin vaatimuksista vastussa olevan tahon kanssa.
Keskusteluun ei saatu lopputulosta diplomityön aikana.
Avainsanat: Toimikortti, NFC, PACE, eRA, eRASmartCard
Jukka Pajulehto: Establishing NFC-connection to healthcare-id cards.
Master of Science Thesis Tampere University
Master of science programme December 2021
In spring 2020 Finnish Digital and population data services agency (DVV) decided to update their Finnish healthcare-id cards. This update included new signature algorithms and more importantly a whole new feature, NFC-connection capability. New NFC-capability makes it easier for the user to authenticate oneself into digital services that use healthcare-id cards for identification. eRA healthcare information service is one of these services. NFC-connectivity improves user experi- ence and reduces reliance on external card readers, especially on mobile platforms. Every mod- ern mobile device contains an internal NFC-reader which can be used to communicate with these id-cards. This makes the authentication process into eRA easier in mobile space, which is why Atostek OY decided to implement NFC-connectivity support into its eRASmartCard software.
eRASmartCard is a card-reader software designed to handle communication between eRA and healthcare-id cards.
To be able to use this new contactless interface in eRA, PACE-protocol must be implemented into the eRASmartCard card-reader-software. PACE is a key exchange protocol used to secure communication between card-reader-software and card. Protocol has been designed by the Ger- man Federal Cyber Authority (BSI) and Germans use the same protocol to secure their id-cards wireless connectivity.
eRA, as a healthcare-information-service, is subject to a third-party security audition. These au- ditions set requirements on id-card authentication. According to these requirements, the card must be within the reader for the whole duration of the user session. Same requirements apply to NFC-connected cards which causes some problems in terms of usability. Keeping a card in the NFC-antenna might not be easy and is prone to accidental disconnections, especially in mobile space. Location of the NFC-antenna might also vary in devices, which might make holding a card in proximity for longer durations close to impossible.
Despite these problems, NFC-capability was still implemented into eRASmartCard. To ensure NFC-implementations auditing compliance, NFC-connected cards state is polled every second.
On removal, a 10 second grace period is granted for the card to reconnect. If the card does not reconnect within these 10 seconds, notification is sent to eRA and the session will be terminated.
Session will also be terminated if eRASmartCard fails to send any status updates for 10 seconds.
NFC-capability was implemented and released into the production environment successfully in Windows, OSX and Android platforms. NFC-capability could not be released into production in eRASmartCards iOS version due to the platform limitations. These limitations made audition com- pliant NFC-implementation impossible. NFC-capability was still implemented into iOS in a non- compliant way as a disabled feature. Feature may be enabled in future if audition requirements shift into a more favorable direction. Discussion about loosening the audition requirements have been started with the relevant parties. These discussions did not resolve within the duration of this thesis.
Keywords: Smartcard, NFC, PACE, eRA, eRASmartCard
Diplomityö toteutettiin Atostek Oy organisaatiolle osana eRASmartCard kortinlukijasovelluksen kehitystyötä. Kiitän Atostek Oy:tä diplomityön mahdollistamisesta ja tukemisesta. Kiitän myös Terhi Kilamoa ja Jukka Koskista diplomityön ohjaamisesta ja tarkastamisesta.
Tampereella, 14.12.2021
Jukka Pajulehto
1. JOHDANTO ... 1
2.TYÖN LÄHTÖKOHTA ... 2
2.1 eRA ja eRASmartCard ... 2
2.2 Tunnistautuminen eRA järjestelmään ... 4
2.3 Uuden NFC-ominaisuuden rooli eRAan tunnistautumisessa ... 6
2.3.1Sessioon kohdistuvat vaatimukset ... 7
2.3.2Vaatimusten aiheuttamat ongelmat ... 7
3.NFC-TOTEUTUKSEN TAUSTATIEDOT ... 9
3.1 Sirukorttien toiminta ... 9
3.1.1APDU ... 11
3.1.2PC/SC standardi ... 12
3.2 DVV:n toimikorttien toiminta ... 12
3.3 NFC ... 13
3.4 Kryptografia ... 14
3.4.1Hajautus- ja MAC-algoritmi ... 14
3.4.2Elliptisen käyrän kryptografia ... 15
3.4.3Elliptisten käyrien avaimien kardinaliteetti ... 16
3.4.4Diffie-Hellman avaintenvaihto ... 17
4.NFC-YHTEYDEN SUOJAUS ... 18
4.1 PACE-protokolla ... 18
4.2 PACE-protokollan versiot ... 21
4.3 PACE-protokollan toteutus eRASmartCard sovellukseen ... 23
4.3.1Vaihe 1: Protokollan aloitus ... 23
4.3.2Vaihe 2: Satunnaisuuden hakeminen kortilta ... 24
4.3.3Vaihe 3: Satunnaisluvun kuvaus generaattoripisteeksi ... 25
4.3.4Vaihe 4: Diffie-Hellman avaintenvaihto ja avainten derivointi ... 26
4.4 Salatun APDU-komennon muodostaminen ... 27
4.5 APDU-komentojen salauksen purku ... 29
4.6 PACE-protokollan turvallisuus sirukorteissa ... 31
5.TOTEUTUS ERI YMPÄRISTÖILLE ... 33
5.1 Toteutuksen laajuus ... 34
5.2 Toteutuksen tietoturva ... 34
5.3 Android ... 35
5.3.1NFC-ominaisuuden käyttöönotto ... 35
5.3.2PACE-protokollan toteutus ... 37
5.3.3Salaus- ja purkufunktiot... 41
5.3.4Integroiminen olemassaolevaan koodipohjaan ... 44
5.3.5Auditointivaatimusten täyttäminen ... 46
5.3.6Avustavien funktioiden toteutus ... 46
5.4 iOS ... 50
5.4.1 NFC-ominaisuuden käyttöönotto iOS-alustalla ... 51
5.5.1NFC:n käyttöönotto Windows ja OSX ympäristöissä ... 53
5.5.2PACE-protokollan toteutus ... 54
5.5.3Integrointi olemassaolevaan koodipohjaan ... 54
5.5.4Auditointivaatimusten täyttäminen ... 56
6.YHTEENVETO JA LOPPUTULOS ... 57
LÄHTEET ... 59
LIITE A: PACE-PROTOKOLLA GM-VERSIOLLA ... 61
APDU Application Protocol Data Unit.
ATR Answer to Reset.
BAC Basic Access Control
DVV Digi- ja väestövirasto.
DHKE Diffie-Hellman Key Exhange
EC Elliptic Curve.
KDF Key Derivation Function.
MAC Message Authentication Code.
NFC Near-Field-Communication.
PACE Password Authenticated Communication Establishment.
PAKE Password Authenticated Key Exchange.
PKI Public Key Infrastucture
1. JOHDANTO
Suomalaisten potilastietojärjestelmien tunnistautuminen on perustunut erilaisiin sirukortteihin ja niihin tallennettuihin digitaalisiin varmenteisiin terveydenhuollon digitalisoinnin alkuajoista lähtien. Kortit ovat tähän mennessä sisältäneet vain fyysisen käyttöliittymän. Näin ollen toimikorttien käyttö ja tietojärjestelmiin tunnistautuminen on aina vaatinut erillisen kortinlukijan, joka kykenee lukemaan toimikorttia.
Työpöytäkäytössä erillinen kortinlukija toimii hyvin, sillä käyttäjän työpiste on kiinteä.
Mobiilikäytössä tilanne on kuitenkin toinen. Jokainen ylimääräinen laite jota käyttäjä joutuu kuljettamaan mukanaan huonontaa käyttäjäkokemusta.
2010-luvulla älypuhelimet alkoivat yleistymään kuluttajien keskuudessa ja sen myötä alkoi myös terveydenhuollon tietojärjestelmiin kohdistua uusia tarpeita mobiiliystävällisistä käyttöliittymistä. Toimikorttien kehityksestä ja ylläpidosta vastuussa oleva Digi- ja Väestövirasto (DVV) tunnisti tämän tarpeen ja toteutti keväällä 2020 toimikortti uudistuksen, joiden myötä uusiin toimikortteihin tulee fyysisen käyttöliittymän lisäksi myös langaton käyttöliittymä. Yhteys langattomaan käyttöliittymään tapahtuu NFC-protokollan avulla. Jokainen moderni älypuhelin sisältää NFC-antennin sisäänrakennettuna, mikä mahdollistaa toimikorttien käytön ilman erillistä kortinlukijaa.
Langaton yhteysmuoto tuo mukanaan uuden ongelman. Jos toimikortin ja puhelimen välistä yhteyttä ei salata jollain tavalla, voisi kolmas osapuoli kuunnella kommunikointia ja varastaa toimikortin salasanan helposti. Fyysisessä yhteydessä samaa ongelmaa ei ole. Ongelman ratkaisemiseksi toimikorttien langaton rajapinta toteuttaa PACE- protokollan yhteyden suojaamiseksi.
Diplomityössä tavoitteena on tutkia kuinka PACE-protokolla toimii käytännössä DVV:n toimikorteissa ja miten protokollan mahdollistamaa NFC-ominaisuutta voidaan hyödyntää eRA-potilastietojärjestelmässä tunnistautumiseen ja dokumenttien allekirjoittamiseen auditointivaatimusten mukaisesti.
2. TYÖN LÄHTÖKOHTA
Kuten johdannossa tuli ilmi, NFC-tuen toteutus lähti käyntiin DVV:n toimikorttiuudistuksen myötä. Toimikorteissa on ollut jo pitkään NFC-tuki rautapuolella, mutta koska kyseessä on langaton yhteysmuoto ja kommunikointi on luonteeltaan sensitiivistä, täytyy yhteys suojata jollain menetelmällä sovelluspuolella. Tämä suojausmenetelmä, PACE-protokolla, tuli DVV:n toimikortteihin 2020 keväällä [31, sivu 6]. Protokolla mahdollistaa turvallisen kommunikointikanavan muodostamisen hyödyntäen toimikorttiin tallennettua PIN-koodia. Diplomityössä tämä uusi NFC-tuki toteutetaan eRASmartCard-kortinlukijasovellukseen. eRASmartCard on kortinlukijasovellus, jonka tarkoituksena on mahdollistaa terveydenhuollon toimikorttien käyttö tunnistautumiseen eRA-potilastietojärjestelmässä. Molemmat sovellukset omistaa Atostek OY ja kaikki kehitystyö tapahtuu yrityksen sisäisesti, mukaanlukien diplomityön NFC-kehitys.
2.1 eRA ja eRASmartCard
eRA on selainpohjainen potilastietojärjestelmä, joka hyödyntää Kanta-palveluita laajasti.
Kanta-palvelut ovat Suomen valtion ylläpitämiä terveydenhuollon tietojärjestelmiä, joiden tavoitteena on yhtenäistää suomalaisten terveydenhuollon tietojärjestelmien toimintaa.
Ennen Kanta-palveluita jokainen potilastietojärjestelmä toimi omalla tavallaan soveltaen lainsäädäntöä, mikä oli huonoa tiedon liikkuvuuden ja eri järjestelmien yhteensopivuuden kannalta. Yhteiset Kanta-palvelut takaavat sen, että tiedot tallennetaan keskitetysti oikeassa muodossa. Tämä helpottaa tiedon kulkua potilasjärjestelmästä toiseen. eRA toimii rajapintana Kanta-järjestelmien ja asiakkaan välillä tarjoten myös selainpohjaisen käyttöliittymän. Käyttöliittymä on suunnattu asiakkaille, joilla ei ole olemassa aikaisempaa potilastietojärjestelmää tai jotka haluavat siirtyä vanhasta uuteen. Rajapinta on suunnattu muille potilastietojärjestelmien kehittäjille, jotka haluavat hyödyntää Kanta-palveluita omissa järjestelmissään.
eRAn rooli
eRASmartCard on eRA-potilastietojärjestelmän hyödyntämä kortinlukijasovellus.
Sovelluksen tarkoituksena on hoitaa korttikommunikointi DVV:n myöntämiin terveydenhuollon toimikortteihin, joita eRA hyödyntää käyttäjän tunnistamisessa.
Potilastietoja saa käsitellä vain henkilö, joka on tunnistettu vahvasti kyseisellä kortilla.
Alla on kuva eRASmartCard-sovelluksen päänäkymästä.
eRASmartCard Android version päänäkymän kolme eri tilaa eRASmartCard mahdollistaa monia eri korttitoimintoja sekä käyttöliittymässä että http- rajapinnan kautta. Käyttöliittymän kautta tehtäviä toimintoja ovat esimerkiksi PIN- koodien vaihtaminen, kortin lukituksen avaaminen PUK-koodilla ja uuden kortin käyttöönottaminen. eRASmartCard on kuitenkin luonteeltaan ajurisovellus, eli sen päätehtävänä on toimia taustalla piilossa ja reagoida sen http-palvelimeen tuleviin pyyntöihin.
2.2 Tunnistautuminen eRA järjestelmään
Kuten edellisessä luvussa tuli ilmi, eRA hyödyntää tunnistautumiseen DVV:n myöntämiä toimikortteja. Toimikortit sisältävät kaksi eri varmennetta: tunnistautumisvarmenteen ja allekirjoitusvarmenteen. Tunnistautumisvarmennetta hyödynnetään kirjautumisen yhteydessä ja allekirjoitusvarmennetta esimerkiksi sähköisten reseptien allekirjoittamisessa.
Varmenteisiin perustuva tunnistautuminen perustuu niiden sisällä oleviin julkiseen ja yksityiseen avaimeen. Yksityisen avaimen avulla varmenteen omistaja voi tehdä allekirjoituksen, joka toimii todisteena varmenteen omistajuudesta. Varmenteen julkisen avaimen avulla tunnistava osapuoli voi varmistaa että kyseessä on varmenteen
omistajan allekirjoittama viesti. Tämä julkisen avaimen kryptografiaan perustuva tunnistautuminen mahdollistaa sen, ettei tunnistautuvan osapuolen tarvitse jakaa salaisuuttaan tunnistavalle osapuolelle.
Varmenteisiin perustuva tunnistautuminen sisältää usein myös ympäröivän infastruktuurin. Tämä infrastruktuuri määrittelee esimerkiksi miten varmenteita luodaan, varmenteiden keston, kuinka varmenteita voidaan perua, minkälainen on varmennehierarkia jne. Terveydenhuollon toimikorttien tapauksessa DVV hoitaa ympärillä olevaa infrastruktuuria ja määrittelee luotujen varmenteiden elinehdot [22].
Luodut varmenteet tallennetaan sirukortteihin pin-koodilla suojattuna ja kortin luovutuksen yhteydessä hakija tunnistetaan vahvasti esimerkiksi passilla [3]. Kortti on voimassa luontihetkestä seuraavat 5 vuotta [23], mutta sen voi vanhentaa etukäteen soittamalla DVV:n sulkupalveluun kortin hukkuessa [4]. DVV tarjoaa sivuillaan myös toimikorttien varmenteiden juurivarmenteen [2]. Juurivarmennetta tarvitaan varmenneketjun tarkastamiseen ja se pitää asentaa tunnistavaan järjestelmään.
Varmenneketjun validointi on oleellista sillä vain sitä kautta voidaan varmistua että käytetyt varmenteet ovat osana DVV:n ylläpitämää järjestelmää.
Tunnistautuminen eRA potilastietojärjestelmään hyödyntäen DVV:n toimikortteja tapahtuu käytännössä seuraavasti:
• Tunnistava järjestelmä (eRA) pyytää toimikortilta allekirjoitusta viestille x.
• Toimikortti allekirjoittaa viestin tunnistautumisvarmenteen yksityisellä avaimella.
• Tunnistava järjestelmä tarkistaa, että allekirjoitus todentuu toimikortin sisältämän varmenteen julkisella avaimella (kuva 3).
• Tunnistava järjestelmä tarkistaa allekirjoituksen todentaneen julkisen avaimen varmenneketjun (kuva 3).
• Kun varmenneketju ja itse viesti on validoitu, käyttäjä on tunnistettu onnistuneesti.
Tunnistautuminen eRAan
Sama logiikka voidaan toteuttaa esimerkiksi allekirjoitettujen sähköisten reseptien validoinnissa. Lopputuloksena saadaan tieto siitä onko dokumentti varmenteen allekirjoittama vai ei.
2.3 Uuden NFC-ominaisuuden rooli eRAan tunnistautumisessa
Diplomityössä toteutettava NFC-kyvykkyys ei vaikuta teknisesti mitenkään olemassa oleviin tunnistautumismekanismeihin. Tunnistautuminen perustuu samoihin
varmenteisiin samalla tavalla riippumatta yhteyden muodosta. Näin ollen pelkän PACE- protokollan toteuttaminen eRASmartCardiin teoriassa riittäisi NFC-ominaisuuden toimintavalmiiksi saamiseksi ja sen hyödyntämiseen eRA-potilastietojärjestelmässä.
Käytännössä näin ei kuitenkaan ole, sillä eRAan kohdistuvat auditointivaatimukset asettavat rajoitteita tunnistautumisen jälkeen tapahtuvaan session ylläpitoon.
2.3.1 Sessioon kohdistuvat vaatimukset
eRA on Kanta-palveluun suoraan yhteydessä oleva terveydenhuollon tietojärjestelmä.
Kaikki Kanta-palveluihin suoraan yhteydessä olevat potilastietojärjestelmät jaetaan eritasoisiin luokkiin, riippuen integraation ja palveluiden laajuudesta. eRA on kokonaisvaltainen potilastietojärjestelmä, joka käyttää laajasti Kanta-palveluja. Tämän takia eRA luokitellaan A-luokkaan kuuluvaksi järjestelmäksi. Sellaisten järjestelmien kuuluu läpäistä auditointiprosessi, mikä asettaa tiettyjä vaatimuksia ja rajoituksia toiminnan ja tietoturvan kannalta. Jos potilastietojärjestelmälle haluaa A-luokituksen, täytyy sen läpäistä jonkin hyväksytyn tietoturva-auditoijan auditointi. Hyväksytyistä tietoturva-auditoijista pitää listaa valtion organisaatio Traficom [12]. eRA- potilastietojärjestelmälle kohdistuvat vaatimukset yltävät myös eRASmartCard- sovellukseen sillä se on oleellisena osana eRA:n toimintaa.
Suurin auditoinneista tuleva, eRASmartCardiin kohdistuva, vaatimus on se, että kortin tulee olla lukijassa koko käyttäjän session ajan. Jos kortti poistetaan lukijasta, tulee potilastietojärjestelmän käyttäjän sessio katketa. Tämän takia korttia lukevan sovelluksen tulee omata suora kommunikointilinja hyödyntävään potilastietojärjestelmään ja ilmoittaa mahdolliset tilamuutokset reaaliaikaisesti.
Tilamuutokset välitetään push-notifikaatioiden muodossa eRASmartCard:ista eRAan.
2.3.2 Vaatimusten aiheuttamat ongelmat
Vaatimus kortin olemassaolon tarkistamisesta aiheuttaa omat haasteensa NFC- kirjautumisen toteutuksen kannalta. NFC-teknologian suurimpana ja luotettavimpana käyttökohteena on nopeat muutaman sekunnin pituiset kommunikointisessiot, esimerkiksi maksukorttien ja maksupäätteiden välillä. Kun sessiot pitenevät useampaan kymmeneen minuuttiin, saattaa NFC-yhteys terminaalin ja kortin välillä katketa odottamatta. Näin tapahtuu erityisesti NFC-antennin ollessa huono tai heikkotehoinen.
Tämä tuli erityisesti ilmi mobiilipuolen kehityksen osalla. Eri laitteilla on eritehoisia ja laatuisia NFC-antenneja, jolloin NFC-ominaisuuden luotettavuuden vaihtelevuus on
suurta. Tämän lisäksi NFC-antennin sijainti ei ole myöskään standardoitu mobiililaitteisssa. Jos NFC-antenni on yläreunassa, kuten Apple-laitteissa, ei kortin pitäminen NFC-antennin lähettyvillä ole realistista pidempien sessioiden osalta.
Näistä ongelmista huolimatta NFC-tuki toteutettiin eRASmartCardin Windows/OS X ja Android-versioille. Ongelman lievittämiseksi jokaiselle alustalle tehtiin NFC-timeout- ominaisuus, jonka tehtävänä on sallia NFC-toimikortin poistuminen NFC-lukijasta maksimissaan 10 sekunniksi. Signaali kortin poistumisesta lähetään potilastietojärjestelmälle tämän jälkeen. Tämä mahdollistaa session pelastamisen, jos kortin laittaa takaisin lukijaan tämä aikavälin sisällä. NFC-tuki toteutettiin myös osittain iOS-alustalle tulevaisuutta varten.
3. NFC-TOTEUTUKSEN TAUSTATIEDOT
NFC-tietoturvaprotokollan toteutuksen ymmärtämiseksi tässä luvussa käsitellään aiheeseen liittyvät taustatiedot. Näitä taustatietoja ovat sirukorttien toiminta, DVV:n toimikorttien toiminta, NFC ja aiheeseen liittyvä kryptografia. Sirukorttien ja DVV:n toimikorttien toiminnan ymmärtäminen on oleellista sillä eRASmartCard:in on tarkoituksena mahdollistaa NFC-kommunikointi DVV:n myöntämiin toimikortteihin.
Kryptografian käsittely on oleellista NFC-kommunikoinnin suojaamiseen käytetyn PACE- protokollan ymmärtämiseksi.
3.1 Sirukorttien toiminta
DVV:n uudet toimikortit on toteutettu sirulle Citiz 2.17i johon on asennettu sovellus Id.me 1.6i [24, luku 1.1]. Citiz 2.17i kortti on toteutettu ISO-14443-A standardin mukaisesti.
Standardi määrittelee sirukortin seuraavat ominaisuudet [25]:
1. Fyysiset ominaisuudet. Minkälainen on kortin fyysinen rakenne.
2. Käytetty taajuus ja signaalinkäsittely. Määrittelee käytettyjen radioaaltojen parametrit ja kuinka signaaleja tulee lähettää/tulkita
3. Alustus ja yhteentörmäyksen esto. Määrittelee kuinka yhteys aloitetaan kantamalla oleviin siruihin ja estetään mahdolliset yhteentörmäykset.
Yhteentörmäyksien esto takaa sen että istunto muodostetaan vain yhteen korttiin kerralla.
4. Tiedonsiirtoprotokolla. Määrittelee ylemmällä tasolla kuinka dataa lähetetään ja vastaanotetaan.
Käytetty standardi määrittelee hyvin pitkälle tuettujen kortinlukijoiden valikoiman.
Yleensä kortinlukijat tukevat useita, yleisesti käytössä olevia standardeja.
Kun tehdään kehitystyötä hyödyntäen olemassa olevia sirukortteja, kohdistuu mielenkiinto pääasiassa ISO-standardin neljänteen osioon, tiedonsiirtoprotokollaan.
Muut osiot on kohdistettu alemman tason kehittäjille, esimerkiksi kortinlukijoita tehdessä.
Tiedonsiirtoprotokolla määrittelee kuinka lähetettävä data tulee formatoida ja vastaanotettava data tulkita. Tätä formaattia kutsutaan nimellä ”Application Protocol Data Unit” (APDU). APDU-komennot ovat määritelty ISO-7816 standardissa, joka käsittelee kontaktillisten sirukorttien toimintaa. ISO-14443 on jatke standardille ISO- 7816, minkä takia tiedonsiirtoprotokolla on täysin sama kontaktillisessa ja
kontaktittomassa kommunikoinnissa. APDU-komentojen rakennetta käsitellään tarkemmin seuraavassa luvussa.
Tiedonsiirtoformaatin lisäksi kehitystyössä tulee tietää sirukorttiin asennetun sovelluksen määrittelyt. ISO-14443 määrittelee kommunikointiprotokollan ja osan APDU- komennoista, mutta tarkemmat sovelluskohtaiset tiedot ja toiminnallisuudet tulee hakea sovelluksen kehittäjiltä. Näitä tietoja ovat esimerkiksi tiedostojärjestelmän rakenne, tuetut toiminnot, tiedostojen sijainnit ja lukuoikeuksien hallintatiedot.
Sovelluksen ja sirukortin välinen kommunikointi tapahtuu alla olevan kuvan mukaisesti.
Sirukorttia hyödyntävä sovellus lähettää PC/SC-rajapinnan avulla APDU-komennon lukijalle käsiteltäväksi SCardTransmit-funktiolla. Lukija tulkitsee viestin ja tarkistaa CLA- tavun. Jos CLA-tavu on 0xFF, kyseessä on kortinlukijaan kohdistuva APDU-komento.
Muissa tapauksissa APDU-komento lähetetään lukijan toimesta sirukortille. Sirukortti lähettää vastaussanoman lukijalle ja lukija edelleen lähettää sanoman PC/SC-ajurille.
Sovellus saa vastaussanoman SCardTransmit-funktion paluuarvoista. Tarkempaa tietoa PC/SC ajurin toiminnasta on luvussa 3.1.2.
Sovelluksen ja sirukortin välinen kommunikointi [8, luku 2.1]
3.1.1 APDU
APDU on sirukortin ja terminaalin välisessä kommunikoinnissa käytetty tietoyksikkö.
APDU-komentojen rakenne näkyy alla olevassa kuvassa.
APDU-komentojen rakenne.
APDU rakenne voidaan jakaa kahteen eri osioon: Header ja Body. Header osio on kaikissa APDU-komennoissa pakollinen ja se sisältää tiedot komennon luokasta (CLA), käskystä (INS) ja käskyparametreista (P1 ja P2). Jokainen näistä kentistä on yhden
tavun pituinen. Monet toiminnallisuudet vaativat vain header-osion, sillä INS-, P1- ja P2- arvot yleensä sisältävät kaiken tarpeellisen datan toiminnon suorittamiseen. Jotkin toiminnallisuudet kuitenkin vaativat sen että liitteeksi pystyy antamaan lisädataa. Tällöin voidaan lisätä Body-osio, joka koostu Lc-, Data- ja Le-kentistä. Lc-kenttä määrittelee Data-kentän pituuden, Data-kenttä sisältää itse viestin ja Le-kenttä kertoo vastauksen odotetun pituuden. Esimerkiksi jos sirukorttiin asennettu sovellus tukee allekirjoituksien tekoa, tulee allekirjoitettava data antaa Body-osion Data-kentässä.
3.1.2 PC/SC standardi
PC/SC on ISO-7816 standardiin perustuva ohjelmistokirjasto ja middleware komponentti, joka mahdollistaa helpon kommunikoinnin sirukorttien kanssa. PC/SC toimii hyödyntävän sovelluksen ja kortinlukijan ajurin välissä. Ilman PC/SC standardia jokaiselle kortinlukijalle pitäisi tehdä erillinen tuki hyödyntävässä sovelluksessa.
PC/SC standardia käytetään Windows, Linux ja OS X ympäristöissä korttikommunikointiin Windows ympäristössä käytetään WinSCard-rajapintaa, mutta kyseinen rajapinta on identtinen PC/SC:n kanssa yhteisten toiminnallisuuksien osalta.
WinSCard-rajapinta sisältää PC/SC-rajapinnan kanssa yhteisten komentojen lisäksi myös omia komentoja. Android ja iOS ympäristöt eivät oletusarvoisesti sisällä PC/SC middleware:a minkä takia jokaisen kortinlukijavalmistajan täytyy tehdä oma kirjasto korttikommunikointia varten näille alustoille.
3.2 DVV:n toimikorttien toiminta
Kuten kaikki muutkin sirukortit, sisältää DVV:n toimikortit omaan käyttötarkoitukseen tehdyn sovelluksen. DVV:n toimikortit voivat sisältää kahden tyyppisiä sovelluksia: fineid tai id.me. Fineid-sovellusta on käytetty kaikissa toimikorteissa 2004-luvulta lähtien. 2020 keväällä DVV siirtyi käyttämään id.me sovellukseen perustuvia toimikortteja [26, sivu 4].
Nämä molemmat sovellukset on tehty IAS ECC -määrittelyjen mukaisesti. Tämä dokumentti määrittelee tarkkaan minkälaisia toiminnallisuuksia eurooppalaisten henkilökorttien tulee tukea ja millä APDU-komennoilla niihin pääsee käsiksi. Dokumentti määrittelee myös tiedostojen hallintaa ja tiedostojärjestelmän rakennetta. Dokumentti pohjautuukin ISO-14443 ja ISO-7816 määrittelyihin. Eli ISO-14443 ja ISO-7816 määrittelivät sirukorttien yleisen toiminnan sekä rauta-, että ohjelmistotasolla ja IAS ECC dokumentti määrittelee EU:ssa käytettävien henkilökorttien toiminnan ohjelmistotasolla.
Tämä takaa sen, että toimikortteja voidaan hyödyntää jokaisessa EU-maassa.
DVV:n toimikorttien päätavoitteena on varastoida henkilön digitaalinen identiteetti. Tämä identiteetti on tallennettu sirukorttiin varmenteena id.me- tai fineid- sovelluksen sisälle.
Kaikki toimikortin toiminnallisuudet liittyvät jotenkin sen sisälle tallennettuihin varmenteisiin tai niiden pääsynhallintaan. Suoraan varmenteisiin kohdistuvia ominaisuuksia ovat esimerkiksi varmenteen lukeminen ja allekirjoituksen tekeminen vastaavalla yksityisellä avaimella. Pääsynhallintaan kohdistuvia toimintoja on esimerkiksi toimikortin aktivointi ja PIN-koodien vaihtaminen.
Toimikortit sisältävät kaksi eri varmennetta: tunnistautumisvarmenteen ja allekirjoitusvarmenteen. DVV määrittelee näille varmenteille erilaiset käyttötarkoitukset eikä näitä saa käyttää muihin tarkoituksiin. Tunnistautumisvarmennetta käytetään vahvaa tunnistautumista vaativiin palveluihin tunnistautumiseen ja allekirjoitusvarmennetta käytetään digitaalisten dokumenttien allekirjoittamiseen.
Esimerkkinä digitaalisesta dokumentista on digitaaliset reseptit. Nämä tulee allekirjoittaa reseptin tekijän toimesta hyödyntäen hänen toimikorttinsa allekirjoitusvarmennetta.
Toimikortin haltija on vastuussa kortillaan tehdyistä toimista oikeudellisesti ja taloudellisesti [9, luku 2.6]. Tämän takia toimikorttien varmenteet on suojattu erillisillä PIN-koodeilla väärinkäytön rajoittamiseksi. Kortin käyttöönottovaiheessa käyttäjän tulee määritellä tunnistautumis- ja allekirjoitusvarmenteille omat PIN-koodinsa. Diplomityössä PIN1-koodi viittaa tunnistautumisvarmenteen koodiin ja PIN2-koodi allekirjoitusvarmenteen koodiin. PIN-koodi koostuu kokonaisluvuista ja sen tulee olla pituudeltaan 4 – 8 merkkiä [21, sivu 4]. Nelimerkkinen PIN-koodi ei ole kovin turvallinen itsessään. Tämän takia PIN-koodeilla on vain 4 yrityskertaa, jonka jälkeen kortti menee lukkoon. Yrityskertojen rajaaminen neljään antaa nelimerkkisellekin PIN-koodille melko hyvän turvallisuuden. Lukituksen saa auki vain kortin lunastamisen yhteydessä annetun PUK-koodin avulla. Jos PUK-koodin hukkaa, ei kortin lukituksen avaaminen ole mahdollista.
Varmenteiden pääsynhallinta tulee esille NFC-toteutuksessa. NFC-yhteyden langattomuus mahdollistaa uusien hyökkäysmenetelmien toteuttamisen minkä takia NFC-rajapinnan kautta varmenteiden lukuun kohdistuu ylimääräisiä rajoitteita. Näistä enemmän tietoa luvussa 4.1.
3.3 NFC
Near-Field Communication (NFC) on lyhyen kantaman langattomaan kommunikointiin käytetty kommunikointiprotokolla. NFC on protokollana jo melko vanha ja se hyväksyttiin osaksi ISO/IEC standardia vuonna 2004 [10]. NFC eroaa muista lyhyen kantaman
kommunikointiprotokollista siten että NFC:ssä toinen lukija tarjoaa luettavalle osapuolelle myös virtaa induktion muodossa. Tämän takia NFC:tä käytetäänkin erilaisten pääsykorttien ja maksukorttien kanssa langattomaan kommunikointiin.
Luettava osapuoli ei tarvitse omaa virtalähdettä. Tämä takaa sen, että pääsykortit ja maksukortit ovat erittäin pitkäikäisiä ja halpoja valmistaa.
Standardin mukainen NFC-lukija kommunikoi 13.56MHz taajuudella [1], tarjoten maksimissaan 424 kt/s tiedonsiirtonopeuden. Nykyisella mittapuulla nämä nopeudet ovat kovin alhaiset. Sähköiset tunnistautumismenetelmät perustuvat lähes aina jonkin tyyppisiin varmenteisiin, jolloin tunnistautuminen vaatii vaan allekirjoitukset tekemisen.
Allekirjoituksien koot ovat pienet, jonka takia NFC:n tiedonsiirtonopeudet ovat riittävät.
NFC ja sitä tukevat älykortit sopivat hyvin digitaaliseen tunnistamiseen pitkäikäisyyden, virtalähteestä riippumattomuuden ja tarpeeksi nopean tiedonsiirtonopeuden takia.
3.4 Kryptografia
NFC-yhteyden muodostamiseen käytettävän PACE-protokollan toteutukseen käytetään monia eri kryptografisia funktiota ja joissakin tilainteissa joudutaan käyttämään kryptografisten kirjastojen alemman tason funktiota. Tämän takia on oleellista käsitellä aiheeseen liittyvää kryptografiaa.
3.4.1 Hajautus- ja MAC-algoritmi
Hajautusalgoritmien tehtävänä on luoda digitaalinen, kiinteän kokoinen sormenjälki tiedostosta. Esimerkiksi SHA256-algoritmi tuottaa aina 256-bitin tiivisteen, riippumatta annetun datan koosta. Hajautualgoritmit ovat ”one-way” funktiota, eli loppuarvosta on erittäin vaikea laskea alkuarvo. Tämä takaa sen, että hajautusalgoritmia voidaan pitää digitaalisena sormenjälkenä, sillä tiivisteen väärentäminen laskennallisesti haastava ongelma. Turvallisina pidettyjä hajautusalgoritmeja ovat esimerkiksi SHA256 ja SHA512.
Hajautusalgoritmeja hyödynnetään erilaisissa kryptografisissa protokollissa laajasti.
Monet protokollat vaativat alkuarvojen muokkaamisen sopivampaan muotoon esimerkiksi tilankäytön suhteen. Tällöin hajautusalgoritmien avulla alkuarvot voidaan tiivistää sopivan kokoisiksi. Tarkistus-summa-algoritmi MAC (Message Authentication Code) on yksi tiivisteitä hyödyntävä kryptografinen algoritmi. Algoritmin tarkoituksena on muodostaa MAC-koodi, jolla vastaanottava osapuoli voi varmistaa viestin alkuperän.
MAC-algoritmissa vahvistettava viesti ensin tiivistetään SHA-hajautusalgoritmillä.
Tämän jälkeen tiiviste salataan molemmilla osapuolilla tiedossa olevalla salausavaimella. MAC-koodi lähetetään viestin mukana vastaanottavalle osapuolelle.
Vastaanottava osapuoli voi varmistua siitä että viesti on oikean tahon lähettämä purkamalla MAC-koodin yhteisellä salaisuudella ja tiivistämällä viestin sovitulla hajautusalgoritmilla. Jos purettu MAC-koodi ja viestin tiiviste ovat samat, voidaan viesti todeta alkuperäiseksi. PACE-protokollassa MAC-algoritmiä käytetään turvallisessa kommunikoinnissa tarkistussummien laskemiseen.
3.4.2 Elliptisen käyrän kryptografia
PACE-protokollassa elliptisiä käyriä käytetään Diffie-Hellman avaintenvaihdossa avainparien generointiin. Elliptisten käyrien tarkemmat toimintaperiaatteet tulee tietää sillä avaintenvaihtoon käytetyn elliptisen käyrän domain-parametrit määritellään erikseen protokollan kuvausvaiheessa. Avaintenvaihto tulee toteuttaa näillä erikseen määritellyillä domain parametreilla.
Elliptiset käyrät (EC) ovat yksi menetelmä muiden joukossa avainparien generointiin julkisen avainten kryptografisissa systeemeissä. Elliptisen käyrän kryptografian etuna on lyhyet avaimet. Elliptisen käyrän 256-bitin avaimet vastaa tietoturvaltaan 3072-bitin RSA- avainta. RSA:n ainoana etuna on nopeampi validointi. Yksityisiä avaimia sisältävien toimikorttien päätehtävänä on kuitenkin tehdä allekirjoituksia, missä EC-pohjaiset avaimet ovat nopeampia. Tämä seikka ja pienemmät avaimet tekevät EC-avaimista käytännöllisempiä resurssien kannalta rajallisessa sirukorttiympäristössä. Pienemmät allekirjoitukset ovat myös etu tilankäytön suhteen tietokantoihin tallennettujen allekirjoitettujen dokumenttien näkökulmasta. Näiden seikkojen takia DVV aikoo siirtyä käyttämään elliptisiä käyriä henkilövarmenteissaan tulevaisuudessa.
Elliptisiä käyriä käytetään PACE-protokollassa kahdessa eri kohtaa: kuvausvaiheessa ja avaintenvaihtovaiheessa. Molemmissa tapauksissa EC-avaimia käytetään Diffie- Hellman avaintenvaihdon toteuttamiseen.
Kuvausvaiheen ymmärtämiseksi täytyy ymmärtää Elliptisen käyrän avainparin generoimisen toimintamallit. EC-avainpari generoidaan nimensä mukaisesti jostain standardin mukaisesta elliptisen käyrän funktiosta. Erilaiset standardit määrittelevät joukon ”domain” arvoja, joilla generoidut avainparit ovat turvallisia. Standardien mukaisten parametrien käyttö on oleellista. Omien arvojen käyttö saattaa johtaa tietoturvaongelmaan. EC-kryptografia määrittelee seuraavat ”domain” parametrit avaimien generointiin [27]:
• Modulus. Määrittelee yksityisen avaimen ylärajan. Jos EC-algoritmi käyttää 256 bittisiä avaimia, on modulus 2256.
• Generator Point. Piste jota käytetään kaikkien avainten generoinnin alkupisteenä.
• Order. Määrittelee kaikkien mahdollisten pisteiden lukumäärän käyrällä. Tämä on pienempi kuin modulus.
• Cofactor. Määrittelee kuinka monta uniikkien pisteiden muodostamaa aliryhmää käyrällä on.
• Curve. Määrittelee elliptisen käyrän yhtälön. Yhtälö määritellään antamalla arvot a ja b yhtälöstä 1. Esimerkiksi secp256k1 käyrällä a=0 ja b=7.
𝑦2= 𝑥3+ 𝑎𝑥 + 𝑏 (1)
Nämä arvot määritelevät minkälaisia avaimia EC-algoritmi generoi.
Avainparien generointi elliptisestä käyrästä on nopea ja helppoa. Otetaan esimerkiksi secp256r1 käyrä. Ensimmäisenä generoidaan 256 bitin satunnainen kokonaisluku K.
Tämä K on avainparin yksityinen avain. Julkinen avain P saadaan kun generaattoripiste 𝐺 summataan K kertaa itsensä kanssa (2).
𝑃 = 𝐺 ∙ 𝐾 (2)
Julkisesta avaimesta on mahdollista laskea yksityinen avain alla olevan kaavan 3 mukaisesti. Tämä prosessi on vastakkainen pisteen kertomisprosessiin verrattuna ja se on huomattavasti hitaampi. Ongelmaa kutsutaan elliptisen käyrän diskreetin logaritmin ongelmaksi ja sen ratkaisemiseksi ei ole löydetty tehokkaita algoritmejä. Tämä epäsymmetria kertomisen ja jakamisen laskennallisesta haastavuudesta takaa elliptisestä käyrästä generoitujen avaimen turvallisuuden.
𝐾 =𝑃
𝐺 (3)
3.4.3 Elliptisten käyrien avaimien kardinaliteetti
Kardinaliteetti on käsite joka kuvastaa matemaattisen joukon suuruutta. Elliptisten käyrien tilanteessa kardinaliteetti viittaa mahdollisten pisteiden lukumäärään käytetyssä EC-algoritmissä, eli mahdollisten julkisten avainten lukumäärään. Julkisten avaimien lukumäärä on suoraan yhteydessä algoritmin turvallisuuteen. Matalan kardinaliteetin omaavan EC-algoritmillä mahdollisten avainparien joukko on pienempi. Jos joukko on tarpeeksi pieni, muuttuu yksityisen avaimen laskeminen julkisesta avaimesta laskennallisesti mahdolliseksi kaavan 3 mukaisesti.
Avaimien kardinaliteettiin voi vaikuttaa valitsemalla sellaiset käyrän parametrit ja generaattoripiste, joilla mahdollisten pisteiden määrä on mahdollisimman suuri. Käyrän parametreilla voidaan vaikuttaa parametrin ”Order” suuruuteen, eli teoreettiseen uniikkien pisteiden maksimiarvoon. Generaattoripisteellä voidaan valita mahdollisimman suuri aliryhmä. Näiden seikkojen takia on äärimmäisen tärkeää että käytettyjen käyrien domain parametreinä käytetään yleisesti hyväksyttyjä ja standardoituja arvoja.
3.4.4 Diffie-Hellman avaintenvaihto
Diffie Hellman avaintenvaihto on julkisen avaimen kryptografiaan perustuva salaisuudenvaihtomenetelmä. DHKE mahdollistaa yhteisen salaisuuden muodostamisen turvattoman kommunikointikanavan kautta. DVV:n toimikorttien tapauksessa yhteisen salaisuuden vaativina tahoina on korttia lukeva terminaali ja itse toimikortti. Turvattomana kommunikointikanavana on radioaallot. DH-avaintenvaihto ei ota kantaa yhdistettävän tahon luotettavuuteen. Tämän takia pelkästään DH- avaintenvaihto ei riittänyt DVV:n toimikorttien NFC-yhteyden suojaamiseen ja ratkaisuksi kehitettiin PACE-protokolla.
Itse avaintenvaihtoalgoritmi toimii seuraavin askelin:
• Molemmat osapuolet generoivat EC-avainparit
• Molemmat osapuolet lähettävät oman julkisen avaimen toisilleen.
• Molemmat osapuolet kertovat yksityisen avaimensa vastaanotetulla julkisella avaimella.
• Kerronnan lopputulos on molemmilla osapuolilla sama. Näin saadaan muodostettua yhteinen salaisuus, jota voidaan käyttää esimerkiksi AES- salaukseen.
Diffie-Hellman avaintenvaihto on oleellisessa osana PACE-protokollaa. PACE-protokolla on luonteeltaan avaintenvaihtoalgoritmi ja Diffie-Hellman on se menetelmä, jolla avaimet vaihdetaan ja yhteinen salaisuus muodostetaan.
4. NFC-YHTEYDEN SUOJAUS
NFC-tuen lisäys toimikortteihin toi mukanaan kolme uutta hyökkäysmenetelmää toimikortteihin perustuvaan autentikointiin. Koska kyseessä on langaton yhteysmuoto, on toimikortin tietojen lukeminen mahdollista ilman käyttäjän lupaa jos kortin pääsynhallintaa ei rajoiteta. Voimakkaan NFC-antennin avulla sirukortin tiedot voidaan lukea jopa useiden metrien etäisyydeltä ilman että kortin omistaja on tietoinen asiasta.
Tätä kutsutaan skimmaamiseksi. Toinen NFC-yhteyden mahdollistama hyökkäysmenetelmä on salakuunteleminen, jos kommunikointikanavaa ei suojata mitenkään. Toimikortin ja terminaalin välinen kommunikointi sisältää sensiitivistä dataa, mikä tekee salakuuntelusta ongelman. Kolmas uusi uhka on ”man-in-the-middle”
hyökkäys. Kohteena oleva toimikortti tulee tunnistaa jotenkin. Muuten ei ole taetta siitä että NFC-lukija kommunikoi oikean toimikortin kanssa.
Skimmaus-ongelman korjaamiseksi kaikki toimikorttien read-ominaisuudet on siirretty PIN-koodin taakse NFC-rajapintaa käytettäessä. Tietojen lukeminen vaatii PACE- protokollan muodostamisen. Fyysistä rajapintaa käytettäessä varmenteen tiedot on luettavissa ilman PIN-koodia, mikä tekee fyysisen ja NFC-rajapinnan toiminnasta hieman erilaiset.
Salakuuntelun ja ”man-in-the-middle” ongelmien ratkaisemiseksi saksalainen Federal Cyber Security Authority (BSI) on kehittänyt PACE-protokollan.
4.1 PACE-protokolla
Langaton kommunikointi elektronisiin henkilöllisyystodistuksiin on perustunut Basic Access Control protokollaan vuodesta 2005 lähtien, jolloin Saksa ensimmäisenä toi protokollan omiin sähköisiin passeihinsa. Myöhemmin BAC-protokollasta on kuitenkin löydetty tietoturvaongelmia. Tutkijat onnistuivat esimerkiksi tekemään ”replay-attack”
hyökkäyksen BAC-algoritmeilla turvattuihin passeihin. Tämä hyökkäys mahdollistaa yksittäisten passien seuraamisen [16]. Lisäksi BAC-protokollassa salaukseen käytettävällä avaimella on alhainen entropia [17], mikä tarkoittaa sitä, että salauksen purkaminen on mahdollista ”brute-force” menetelmällä. Näiden tietoturvaseikkojen takia BSI lähti suunnittelemaan uutta kommunikointiprotokollaa passien ja lukijoiden välille.
Uuden protokollan nimi on PACE ja se korjaa kaikki aikaisemman BAC-protokollan heikkoudet.
PACE-protokolla kuuluu PAKE-algoritmien (Password Authenticated Key Exchange) perheeseen [28, sivu 8]. PAKE-algoritmien perheeseen kuuluu esimerkiksi WiFi- yhteyksien turvaamiseen käytetyt algoritmit. Yhteistä PAKE-algoritmeille on se, että molemmilla osapuolilla on yhteinen salaisuus ja tätä salaisuutta hyödyntäen halutaan muodostaa turvallinen kommunikointikanava. WiFi:n tapauksessa yhteisenä salaisuutena on WiFi-salasana, joka on valmiiksi konfiguroitu reitittimeen ja yhdistävään laitteeseen. Tästä salasanasta johdetaan salausavain jollain tuetulla PAKE-algoritmilla ja sitä käytetään viestinnän salaamiseen.
PACE-protokolla toimii melko samalla tavalla. Ympäristönä on vain PACE-protokollan tapauksessa sirukortit ja kortinlukijat. Sirukorttiin tallennetun PIN-koodin ja käyttäjän antaman PIN-koodin avulla muodostetaan turvallinen kommunikointikanava. Tämä estää ”man-in-the-middle” tyypin hyökkäykset, sillä hyökkääjän pitäisi tietää tämä PIN- koodi toisen osapuolen esittämiseksi. Avaintenvaihdon lopputuloksena saadut salausavaimet ja niillä salattu kommunikointi taas estävät salakuuntelun.
DVV:n toimikorteissa PACE-protokolla hyödyntää henkilövarmenteen PIN-koodia, eli PIN1-koodia. Protokolla ei kuitenkaan rajoitu pelkästään varmenteiden PIN-koodeihin, vaan voidaan tunnistamiseen käyttää jotain muuta korttiin tallennettua salaisuutta. Tämä kuitenkin riippuu siitä miten PACE-protokolla on integroitu sirukorttiin. DVV:n tapauksessa vain PIN1-koodia käytetään PACE-protokollan muodostamiseen.
PACE-protokolla koostuu yksinkertaisesti selitettynä seuraavista askelista kuvan 5 mukaisesti.
• Alustusvaihe, jossa määritellään käytettävä PACE-algoritmi ja salaisuuden tyyppi. DVV:n tapauksessa tyyppinä on PIN-koodi.
• Satunnaisuuden generointivaihe. Tässä vaiheessa toimikortti generoi satunnaisen tavujonon jota kutsutaan nonce:ksi. Nonce välitetään kortinlukijasovellukseen salattuna ja salauksen avaimena käytetään PIN-koodia.
• Kuvausvaihe. Vaiheessa siirretään nonce:en varastoitu satunnaisuus elliptisen käyrän generaattoripisteeseen [5, luku 4.4.1].
• Kuvausvaiheen jälkeen siirrytään avaintenvaihtoon. Ensin generoidaan EC- avainpari edellisen vaiheen generaattoripistettä hyödyntäen. Tämän jälkeen avainparin avulla tehdään Diffie-Hellman avaintenvaihto. Lopputuloksena on yhteinen salaisuus.
• Avaintenvaihdon lopputuloksena saadusta salaisuudesta johdetaan vielä kaksi erillistä avainta: Salausavain ja MAC-avain. MAC-avaimen avulla generoidaan todennustunnus, joka vielä lähetetään toimikortille varmennettavaksi.
PACE-protokollan askeleet yksinkertaistettuna.
Se, että PACE-protokolla vaatii PIN1-koodin yhteisen salaisuuden muodostamiseen aiheuttaa jonkin verran rajoitteita NFC-yhteyden kautta mahdollisten korttitoimintojen valikoimaan. Koska yhteyden muodostus on riippuvainen PIN1-koodista, korttia ei voi käyttää NFC:n kautta jos PIN1-koodi on lukkiutunut tai jos korttia ei ole aktivoitu. PIN1- koodin lukituksen avaaminen PUK-koodilla ja kortin aktivoiminen voidaan vain tehdä fyysisen yhteyden välityksellä. Kaikki muut toiminnot toimivat samalla tavalla sekä
langattomassa, että fyysisessä yhteydessä. Alla on lista tuetuista ominaisuuksista riippuen yhteysmuodosta.
Tuetut korttioperaatiot eri yhteysmuodoille.
4.2 PACE-protokollan versiot
PACE-protokollasta on monia eri versioita, jotka eroavat toisistaan käytettyjen kryptografisten algoritmien puolesta. Versiot on nimetty 7-osaisesti, esimerkkinä PACE- ECDH-GM-AES-CBC-CMAC-256. Kyseinen algoritmi käyttää ECDH-algoritmiä yhteisen salaisuuden muodostamiseen, Generic Mapping-algoritmiä EC-domain parametrien määrittelyyn, AES-algoritmiä viestien salaamiseen ja CBC-CMAC-algoritmiä tarkistussumman laskemiseen. Viimeinen osio viittaa käytettyjen avaimien pituuteen kaikissa algoritmeissä. Alla on kaksi listaa kaikista mahdollisista PACE-versioista.
Kaikki PACE-algoritmit [11, luvut 4.4.3.1 ja 4.4.3.2]
Suurimpana erottavana tekijänä eri PACE-versioissa on kuvausvaiheeseen käytetty algoritmi. Kuvaukseen voidaan käyttää joko Generic Mapping (GM) tai Integrated Mapping (IM) algoritmiä. Molemmat menetelmät omalla tavallaan muuttavat PACE- protokollan toisessa vaiheessa saadun satunnaisluvun elliptisen käyrän generaattoripisteeksi. Diplomityössä PACE-protokollan toteutus rajoittui vain GM- menetelmään, minkä takia IM-menetelmää ei käsitellä yhtä tarkasti kuin GM- menetelmää.
PACE-protokollan toteutuksessa täytyy perehtyä sekä BSI:n dokumentaation että DVV:n omiin korttimäärittelyihin. BSI määrittelee protokollan yleisen toteutuksen ja DVV tarkemmat korttikohtaiset määrittelyt, esimerkiksi PACE-protokollaan käytettävän PIN-
koodin tunnisteen. Seuraavassa luvussa käsitellään PACE-protokollan toteutusta, nojautuen DVV:n ja BSI:n määrittelyihin.
4.3 PACE-protokollan toteutus eRASmartCard sovellukseen
PACE-protokolla koostuu monesta eri kryptografisesta funktiosta ja sen voi jakaa toteutuksen näkökulmasta neljään eri osaan: protokollan aloitukseen, satunnaisuuden generointiin, kuvausvaiheeseen ja avaintenvaihtoon. Seuraavissa luvuissa käsitellään PACE-protokollan GM-version toteutus kortinlukijapuolella teoriassa. Jokainen askel käsitellään tarkasti kortille lähetettyjen APDU-viestien tasolla. PACE-protokollan GM- version kaikki askeleet löytyvät tarkasti liitteestä A.
4.3.1 Vaihe 1: Protokollan aloitus
Ensimmäisessä vaiheessa terminaali muodostaa PACE-protokollan initialisointiviestin ja lähettää sen sirukortille. Initialisointiviesti koostuu kolmesta data-objektista (DO) kuvan 4 mukaisesti. DO80 määrittelee käytetyn PACE-algoritmin. Tämä algoritmi määrittelee tiivistys-, tarkistussumma- ja salausalgoritmit ja millä elliptisellä käyrällä EC-avainparit generoidaan. DVV:n toimikortit tukevat kahta PACE-algoritmiä: PACE-ECDH-GM-AES- CBC-CMAC-256 ja PACE-ECDH-IM-AES-CBC-CMAC-256. Nämä algoritmit eroavat toisistaan vain kuvausvaiheeseen käytetyn algoritmin suhteen. DO83 määrittelee protokollassa käytetyn salaisuuden tyypin. Arvo 0x11 tarkoittaa sitä, että autentikointiin käytetään kortin tunnistautumisvarmenteen PIN-koodia. DO84 kertoo käytettävän salaisuuden tunnisteen kortin sisällä. Näin kortti osaa käyttää oikeaa salaisuutta PACE- protokollan muodostamiseen.
PACE-protokollan aloituskomento
Jos protokollan aloitus onnistui, sirukortin tulisi lähettää vastauksena 0x90 ja 0x00 status-tavuina. Status tavujen virallinen nimi on ”Status Word” ja niihin viitataan tässä dokumentissa ja myös kaikissa muissakin dokumenteissa lyhenteillä SW1 ja SW2.
Protokollan aloitus voi epäonnistua jos data-objektit on muodostettu väärin. Tällöin vastauksena tulee virhekoodi SW1 ja SW2 status-tavuihin tallennettuna. Virhekoodit voidaan kääntää selkokielisiksi virheviesteiksi esimerkiksi dokumentin ”Organizational Cards – S1 Electronic ID Application” avulla [29].
4.3.2 Vaihe 2: Satunnaisuuden hakeminen kortilta
Toisessa osiossa terminaali hakee satunnaisluvun, eli nonce:n, toimikortilta alla olevalla komennolla.
Salatun nonce:n hakukomento
APDU-komennon header osuuden CLA-tavu (luku 3.1.1) muuttuu arvoksi 0x10, mikä osoittaa että turvallinen kommunikointikanava on käynnissä tai alkamassa. Nonce on salattu ja se tulee purkaa käyttämällä terminaalille annettua PIN1-koodia käyttäen.
Ennen purkua, PIN1-koodi kuitenkin tulee laittaa KDF:n (Key Derivation Function) lävitse. Vasta SHA256-algoritmillä tiivistettyä arvoa käytetään purkuoperaatiossa. Alla on flow-diagrammi KDF-funktion toiminnasta.
KDF-funktion toiminta
Lopputuloksena oleva tiiviste on AES-salausavain. Tämän avaimen avulla sirukortilta saatu salattu nonce voidaan purkaa selvätekstiseksi. Tätä selväteksistä nonce:a käytetään seuraavassa vaiheessa domain parametrien määrittelyyn.
4.3.3 Vaihe 3: Satunnaisluvun kuvaus generaattoripisteeksi
Kolmannessa vaiheessa nonce:en tallennettu satunnaisuus kuvataan Elliptisen käyrän generaattoripisteeksi. Generaattoripiste yksi domain-parametri muiden domain- parametrien joukossa. Domain parametrien tehtävänä on määritellä minkälaisesta elliptisestä käyrästä avaimet generoidaan. PACE-protokollassa vain domain- parametrien generaattoripiste-muuttujaa muokataan, muut arvot jätetään secp256r1- käyrää vastaaviin arvoihin. DVV:n toimikorttien PACE-versio käyttää kyseistä käyrää avaintenvaihtoihin [30, luku 3.2]. Kuvaus generaattoripisteen x- ja y-koordinaateiksi tapahtuu joko GM- tai IM-menetelmällä. Jos ensimmäisessä vaiheessa määrittelymenetelmäksi valittiin GM, lähetetään kortille secp256r1-käyrästä generoidun avainparin julkinen avain. Jos taas valittiin IM, lähetetään kortille terminaalissa generoitu nonce.
Julkisen avaimen lähetyskomento GM-vaihetta varten.
Kun sirukortti ja kortinlukijasovellus ovat vaihtaneet julkiset avaimet tai nonce:t onnistuneesti, siirrytään itse generaattoripisteen laskemiseen. GM-menetelmällä generaattoripiste määritellään tekemällä Diffie-Hellman avaintenvaihto käyttämällä edellisen APDU-komennon vastauksena saatua julkista avainta. Tämän lopputuloksena on salainen piste secp256r1-käyrällä. Tämä salainen piste kerrotaan vaiheessa yksi saadulla nonce:lla ja lopputuloksena on uusi generaattoripiste.
IM-menetelmällä EC-parametrit määritellään syöttämällä terminaalin ja sirukortin generoimat nonce:t AES:llä toteutettuun satunnaislukugeneraattoriin. Siitä saatu arvo kuvataan elliptisen käyrän x- ja y- koordinaateiksi, jolloin saadaan GM-vaiheen tapaan uusi generaattoripiste.
Kuvausvaiheen lopputuloksena on uusi domain-parametrien joukko. GM- tai IM- menetelmällä laskettu generaattoripiste korvaa secp256r1-käyrän standardin mukaisen generaattoripisteen. Muut arvot pidetään oletusarvoisina.
4.3.4 Vaihe 4: Diffie-Hellman avaintenvaihto ja avainten derivointi
Kun avaintenvaihtoon käytettyjen EC-domain-parametrien arvot on laskettu, generoidaan niillä uusi avainpari. Uutta avainparia käytetään Diffie-Hellman avaintenvaihdon toteuttamiseen. Diffie-Hellman avaintenvaihto kortinlukijasovelluksen ja kortin välillä toimii seuraavasti. Ensin kortinlukijasovellus lähettää oman julkisen avaimensa toimikortille alla olevan kuvan mukaisella komennolla. Vastauksena saadaan toimikortin vastaava julkinen avain.
Julkisen avaimen lähetyskomento DHKE:tä varten.
Kun avaimet on vaihdettu, kerrotaan saatu julkinen avain yksityisellä avaimella.
Lopputuloksena on salainen piste elliptisellä käyrällä. Tämän salaisen pisteen x- koordinaatti on avaintenvaihdon lopputuloksena saatava yhteinen salaisuus. Tästä salaisuudesta vielä johdetaan salausavain ja MAC-avain käyttäen edellä mainittua avainten-derivointi-funktiota (kuva 11). Salausavainta käytetään kommunikoinnissa viestien salaamiseen ja purkamiseen. MAC-avaimen avulla generoidaan todennustunnus (authentication token), joka lähetetään sirukortille validoitavaksi.
Todennustunnus rakennetaan määrittelyjen mukaisesti käyttäen CBC-MAC algoritmiä, hyödyntäen AES-algoritmiä lohkonsalaimena jonka avaimena on MAC-avain. Tälle algoritmille syötetään alla olevan kuvan mukainen tavujono, joka sisältää käytetyn PACE-algoritmin tunnisteen ja terminaalipuolen julkisen avaimen.
Todennustunnuksen rakentaminen
Jos todennustunnus on oikea, sirukortti lähettää oman todennustunnuksensa terminaalille validoitavaksi alla olevalla APDU-komennolla. Terminaalin tulee myös validoida vastaanotettu todennustunnus käyttäen MAC-avainta. Jos validoinnit onnistuvat molemmilla osapuolilla, PACE-protokolla on toteutettu onnistuneesti ja sirukortti on valmis vastaanottamaan salattuja APDU-viestejä.
Todennustunnuksen lähetyskomento
4.4 Salatun APDU-komennon muodostaminen
Kun PACE-protokolla on toteutettu ja yhteinen salausavain on luotu, voidaan aloittaa salattu kommunikointi kortinlukijan ja sirukortin välillä. Salattu kommunikointikanava sovelluksen ja kortin välillä pysyy niin kauan kunnes kortista loppuu virta. Kanavan voi myös sulkea tahallisesti lähettämällä salaamattoman APDU-komennon.
Salatun APDU-komennon muodostamisen voi jakaa kahteen osaan. Ensimmäisessä osassa viestikenttä salataan ja toisessa osassa muodostetaan määrittelyjen mukainen APDU-komento.
Datakentän salaaminen tapahtuu kuvan 16 mukaisesti. Ensimmäisenä Send Sequence Counter (SSC) salataan AES-algoritmillä hyödyntäen PACE-protokollasta saatua salausavainta [33, luku 4.4.3.3]. SSC on laskuri joka kertoo kuinka mones APDU-
komento kyseessä on nykyisen session aikana [11, luku 9.8.6.3]. Luku on BSI:n dokumenttien mukaisesti enkoodattu 16 tavuun Big Endian muodossa ja sitä kasvatetaan aina kun APDU-komento lähetetään tai vastaanotetaan onnistuneesti. Jos APDU-komentoja lähetetään enemmän kuin 2128, aloittaa laskuri alusta.
SSC:n salaamiseen käytetään AES-algoritmia CBC (Cipher Block Chaining) lohkonsalausmenetelmällä. Alustusvektorina käytetään nollavektoria. Käytännössä CBC lohkonsalausmenetelmä kuitenkin toimii samalla tavalla kuin ECB-menetelmä (Electronic Code Book) sillä syötetty data mahtuu yhden lohkon sisään. Näin ollen nimenmukaista ketjutusta ei tapahdu ja tilanteessa voi myös vaihtoehtoisesti käyttää ECB-menetelmää. Kun SSC on salattu onnistuneesti, käytetään sitä alustusvektorina datakentän salaamiseen. Lopputuloksena on salattu viesti.
Datakentän salaus.
Kun viesti on salattu onnistuneesti, voidaan siirtyä APDU-komennon rakentamiseen määrittelyjen mukaisesti. Salattu viesti tulee formatoida kuvan 17 mukaisesti. Formaatti koostuu kolmesta eri dataobjektista, DO87, DO97 ja DO8E. DO87:n sisälle tallennetaan salattu viesti, DO97:n sisälle tallennetaan vastaus-APDU:n odotettu pituus ja DO8E sisältää tarkistussumman.
DO87:n ja DO97:n muodostaminen on suoraviivaista. DO8E:n muodostamiseksi täytyy laskea tarkistussumma. Tarkistussumman laskeminen tehdään seuraavasti. Ensin muodostetaan tavujono kuvan 17 toiseksi viimeisen rivin mukaisesti. Tavujono koostuu CH-osuudesta (Command Header), DO87:stä ja DO97:stä. CH-osuuteen pitää listätä 12 täytetavua neljän olemassaolevan tavun lisäksi 16:lla jaollisuuden saavuttamiseksi.
Myös koko CH:n, DO87:n ja DO97:n muodostamaan kokonaisuuteen pitää lisätä samat
täytetavut. Lopputuloksesta lasketaan tarkistussumma CBC-CMAC-algoritmilla käyttäen PACE-protokollasta saatua MAC-avainta. DO8E muodostetaan tämän tarkistussumman 8 ensimmäisestä tavusta. Kun kaikki dataobjektit on rakennettu onnistuneesti, voidaan muodostaa kuvan 17 viimeisen rivin mukainen APDU-komento.
Salattujen APDU-komentojen rakentaminen [11, luku 9.8.5].
4.5 APDU-komentojen salauksen purku
Sirukortin lähettämät APDU-vastaukset sisältävät kolme dataobjektia DO87, DO99 ja DO8E. DO87 sisältää vastausdatan salattuna ja DO99 sisältää salaamattomat SW1- ja SW2-arvot, jotka kertovat komennon tilasta. DO8E sisältää tarkistussumman, jonka avulla voidaan tarkistaa vastaanotetun tiedon eheys. Tarkistussumman tarkistamiseen käytetään PACE-protokollassa määriteltyä mac-avainta.
Vastauksena tulevien suojattujen APDU-komentojen rakenne [11, luku 9.8.5].
Vastaussanoman viestin saa kun purkaa DO87:n käyttäen samaa PACE-protokollassa lopputuloksena saatua salausavainta kuvan 19 mukaisesti. SSC:tä käytetään samalla tavalla salattuna AES-CBC-algoritmin alustusvektorina kuin salausvaiheessa. SSC:n salaamiseen voidaan myös käyttää AES-ECB-algoritmiä saman lopputuloksen saamiseksi kuten luvussa 4.4.
Vastaanotetun DO87-objektin salauksen purku.
4.6 PACE-protokollan turvallisuus sirukorteissa
PACE-protokolla on teoreettisesti todistettu tietoturvalliseksi monessa tutkimuksessa [14, 15]. Protokolla hyödyntää elliptisiä käyriä avaintenvaihdossa ja menetelmän turvallisuus perustuu diskreetin logaritmiongelman haastavuuteen. Tämä ei kuitenkaan tarkoita automaattisesti sitä, että algoritmi on käytännössä turvallinen sillä reaalimaailmassa tietoturvamallinukseen pitää ottaa huomioon myös fyysisen alustan mahdolliset heikkoudet. Näitä ovat esimerkiksi sirukortin alivirroittaminen, sisäisen kellon virhetilat, lämpötilamuutokset ja sähkömagneettinen säteily. Näitä ulkoisia tekijöitä muokkaamalla sirukortti voidaan saada sellaiseen tilaan, että PACE-protokollan tietoturva kärsii.
Lähteessä 13 tutkijat selvittivät teoriassa kuinka PACE-protokollaa hyödyntävään sirukorttiin voitaisiin tehdä vikahyökkäys (fault attack). Paperissa protokollan tietoturvallisuus vaarannettiin injektoimalla kaksi vikaa sirukorttiin. Ensimmäinen vika liittyy avaintenvaihtoon käytetyn EC-käyrän domain-parametreihin. Tavoitteena on manipuloida sirukortti käyttämään vähemmän turvallista EC-käyrää, jolloin yksityinen avain on laskettavissa. Toinen injektoitu vika liittyy avaintenvaihdon lopputuloksena saadun pisteen validointiin. Tavoitteena on rikkoa pisteen validointi, jolloin sirukortti suostuu tekemään avaintenvaihdon väärällä EC-käyrällä. Jos nämä molemmat virheet saadaan injektoitua onnistuneesti, voidaan sessioavain kaapata.
Paperi esittää myös toisen hyökkäysmallin kohdistuen PACE-protokollan vaiheeseen 2.
Käyttämällä Tunstall-Mukhopadhyay hyökkäystä AES-algoritmiä kohtaan, voidaan
mahdollisten avainten joukon pienentää 212 kokoiseksi. PIN-koodi voidaan laskea tästä joukosta helposti.
PACE-protokollan heikkoudet rajoittuvat vain fyysiseen alustaan. Näiden hyökkäysmenetelmien toteuttaminen vaatii paljon tietotaitoa, oikeat työkalut ja pääsyn fyysisesti korttiin. Näiden seikkojen takia hyökkäysmenetelmien riskitaso on alhainen.
5. TOTEUTUS ERI YMPÄRISTÖILLE
Diplomityön tavoitteena oli toteuttaa PACE-protokolla ja mahdollistaa NFC-kirjautuminen eRAan kaikilla eRASmartCard:in versioilla. eRASmartCard:ista on tehty omat versiot Windows, OSX, Android ja iOS alustoille. Molempien ominaisuuksien toteutus jokaiselle alustalle sisälsi seuraavat työn vaiheet:
• Tuen selvitys.
• Kryptokirjaston valinta
• NFC-ominaisuuden käyttöönoton konfigurointi
• PACE-protokollan toteutus. Salaus- ja purkufunktioiden toteutus.
• PACE-protokollan integrointi olemassaolevaan toiminnallisuuteen.
• Auditointivaatimusten mukaisen sessionhallinnan toteutus.
• Testaus
Jokaisen alustan toteutus lähti käyntiin tuen selvittämisestä. Jos alusta tukee ISO-14443 standardiin perustuvia NFC-siruja, siirryttiin kryptokirjaston valintaan. Kryptokirjaston valintaan vaikutti kolme eri tekijää.
• Tukeeko kirjasto tarvittavia kryptografisia funktioita ja tarjoaako se pääsyn alemman tason rajapintoihin, kuten EC-domain parametrien muokkaamisen?
• Onko kirjasto luotettava?
• Kirjasto on helppo integroida osaksi projektia.
Kirjaston valinnan jälkeen tehtiin alustakohtainen NFC-ominaisuuden käyttöönotto projektiin. NFC-ominaísuuden käyttöönoton jälkeen toteutettiin PACE-protokolla valitulla kryptokirjastolla. Tämän jälkeen PACE-protokolla integroitiin osaksi olemassaolevaa koodipohjaa ja tehtiin kortin poiston tunnistaminen auditointivaatimusten mukaisesti.
Viimeisenä vaiheenä suoritettiin testaus, jolla varmistettiin kaikkien ominaisuuksien toimivuus NFC:n välityksellä. Testaus toteutettiin manuaalisesti TestRails palveluun määriteltyjen testitapausten perusteella.
Jokaisen alustan toteutus käsitellään erikseen omassa kappaleessaan. PACE- protokollan toteutus käydään tarkasti lävitse Android alustan yhteydessä. Muiden alustojen osalta PACE-protokollan toteutus käsitellään suoraviivaisemmin ja keskitytään enemmän alustakohtaisten erojen käsittelyyn.
5.1 Toteutuksen laajuus
PACE-protokollasta on monia eri versioita monilla eri algoritmeillä. Kaikkien näiden toteuttaminen olisi turhaa, koska tällä hetkellä eRASmartCard ohjelmistoa käytetään vain suomalaisten terveydenhuollon toimikorttien kanssa kommunikointiin. Suomalaiset toimikortit tukevat vain kahta PACE-algoritmiä: id-PACE-ECDH-GM-AES-CBC-CMAC- 256 ja id-PACE-ECDH-IM-AES-CBC-CMAC-256 [7, luku 6]. Algoritmit poikkeavat toisistaan vain Diffie-Hellman avaintenvaihtoon käytetyn elliptisen käyrän domain parametrien määrittelymenetelmän suhteen. Toisessa käytetään GM-menetelmää, toisessa IM-menetelmää.
Diplomityössä toteutus kohdistuu vain GM-menetelmää käyttävään algoritmiin. DVV:n toimikorttien PACE-protokolla tukee sekä GM- että IM-variantteja. Vaadittavan työmäärän minimoiseksi päätettiin PACE-protokolla toteuttaa vain GM-versiolla alustavasti. NFC-yhteys toimii yhtä hyvin GM- ja IM-versioilla eikä toisen tuen puuttuminen vaikuta tuettujen korttien lukumäärään. Kaikkien NFC:tä tukevien DVV toimikorttien pitäisi tukea molempia PACE-protokollan versioita. Näin ei löydetty syytä molempien versioiden toteuttamiseen. NFC-toteutuksessa otettiin kuitenkin huomioon että tulevaisuudessa voi tulla tarve IM-version toteuttamiselle.
5.2 Toteutuksen tietoturva
Kuten vaatimuksista tuli ilmi (luku 5), on uuden NFC-ominaisuudet tietoturvallinen toteutus tärkeää. Luvussa 4.6 todettiin että PACE-protokolla on todettu teoriassa tietoturvalliseksi. Samassa luvussa todettiin myös että protokolla on myös tarpeeksi tietoturvallinen sirukortteihin toteutettuna. Tämän takia itse protokolla ei aiheuta suurta tietoturvariskiä. Suurin riski ilmenee PACE-protokollan toteutuksessa. Jos PACE- protokollan toteuttaa väärin kortinlukijasovelluksen tai sirukortin puolella, saattaa tietoturva vaarantua.
Tämän diplomityön laajuuteen ei tarvinnut sisällyttää PACE-protokollan toteutusta sirukortin puolella, sillä PACE-protokolla on valmiiksi toteutettu DVV:n antamiin testikortteihin. Tämä helpottaa toteutusta ja vähentää myös kortinlukijapuolen toteutukseen kohdistuvien riskien määrää. Jos protokollan toteuttaa väärin kortinlukijapuolella, ei kortti suostu muodostamaan yhteyttä. Näin protokollaa ei voi tehdä väärin, olettaen että protokolla on toteutettu oikein DVV:n testikortteihin.
5.3 Android
Tämä luku käsittelee Android-puolen NFC-toteutuksen. Toteutuksen kielenä toimi Kotlin, koska olemassaoleva koodipohja on toteutettu Kotlinillä. Kotlin on myös Googlen suosittelema kieli uusien Android-sovellusten kehitykseen. PACE-protokollan toteutuksen tueksi valittiin BouncyCastle-kryptokirjasto, joka sisältää kaiken oleellisen protokollan toteutukseen. Androidin natiivi kryptokirjasto ei soveltunut rajallisuutensa vuoksi.
eRASmartCard sovelluksessa Androidin NFC-ominaisuutta hyödynnettiin jo aikaisemmin toisenlaiseen käyttötarkoitukseen. DVV:n toimikorteissa on jo jonkin aikaa ollut NFC-tuki rautapuolella, niistä oli vain puuttunut ohjelmistopuoli, eli PACE-protokolla.
Tätä rautapuolen NFC:tä oli hyödynnetty kevyen tunnistautumismenetelmän luomiseen.
Tämä kevyt tunnistautumismenetelmä perustui NFC-tunnisteesta ja PIN-koodista laskettuun SHA256-tiivisteeseen. Tämä menetelmä ei hyödynnä korttiin tallennettuja henkilövarmenteita, minkä takia sitä ei voi käyttää vahvana tunnistautumismenetelmänä potilastietojärjestelmiin. Uusi NFC-toteutus ei kuitenkaan saa häiritä vanhaa NFC- toteutusta, sillä osa asiakkaiden järjestelmistä on riippuvaisia tästä. Tulevaisuudessa, kun PACE-protokollaa tukevat kortit yleistyvät asiakaskunnassa, olisi tarkoituksena siirtyä kokonaan pois kevyestä tunnistautumisesta. Syynä tähän on se, että vahva tunnistautuminen on yhtä nopea, helppo ja käytännöllinen kuin kevyt tunnistautuminen PACE-protokollan myötä. Näin ollen kevyt tunnistautuminen on vain huonompi versio, eikä sille ole tarvetta.
Android-puolen toteutus käsitellään seuraavissa osissa. Ensin käsitellään NFC- ominaisuuden käyttöönottaminen Android-sovelluksessa ja mitä NFC-protokollia Android käyttöjärjestelmä tukee. NFC-ominaisuuden käyttöönoton jälkeen käsitellään PACE-protokollan toteutus esimerkkikoodien avulla. Protokollan toteutuksen jälkeen siirrytään NFC-kirjautumisen toteuttamiseen auditointivaatimusten mukaisesti.
Viimeisessä kappaleessa listataan vielä PACE-protokollan toteutukseen käytetyt avustavat funktiot ja niiden toteutukset.
5.3.1 NFC-ominaisuuden käyttöönotto
Androidin ydinkirjastoihin kuuluu NFC:n hallinnointia hoitava kirjasto. Tämä kirjasto löytyy nimellä ”android.nfc” ja se sisältää kaikki NFC toiminnallisuudet mitä Android tukee. Kyseinen kirjasto tukee seuraavia NFC-standardeja/teknologioita.
