FI125071B - Maksujärjestelmä - Google Patents

Description

MAKSUJÄRJESTELMÄ

Keksinnön kohteena on maksujärjestelmä sähköisen ja varmistetun maksutiedon tuottamiseksi maksun saajalle, johon maksujärjestelmään kuuluu käyttäjän päätelaite käsittäen edelleen maksusovelluksen maksupyyntöjen muodostamiseksi, luotetun alueen ohjelmallisen salauselementin tallentamista ja käyttöä varten, RFID-yhteysvälineet maksutiedon toimittamiseksi maksun saajan päätelaitteeseen, yhteysvälineet palvelinjärjestelmään suojattua yhteys-protokollaa käyttäen, ja salauselementtiin liittyvät välineet maksusovelluksen käyttöoikeuden ohjaamiseksi päälle ja pois, toimijan palvelinjärjestelmä käsittäen edelleen hallintasovelluksen päätelaitteen tunnistamiseksi ja hallinnoimiseksi, tietokannan käyttäjäkohtaisia tietoja ja avaimia varten mukaan lukien kunkin maksusovelluksen salaisuuden, yhteysvälineet päätelaitteeseen suojattua yhteysprotokollaa käyttäen.

Tunnetuissa maksujärjestelmissä toimijoita on useita ja niiden välinen vuorovaikutus ja yhteistyö edellyttävät monimutkaisia järjestelmiä sekä luottamussuhdetta toimijoiden välillä, jolloin kustannukset lisääntyvät jokaisen toimijan kustannusten multip-likaationa. Tekniikan tason järjestelmiä on vaikea tai mahdoton toteuttaa ilman teleoperaattoreita, mikä osaltaan lisää maksujärjestelmien monimutkaisuutta.

Tekniikan tasosta tunnetaan SIM-kortin käyttöön perustuvia järjestelmiä, joita ovat esimerkiksi julkaisuista FI 117586 B ja FI 104937 B tunnetut järjestelmät ja menetelmät. Näissä tilaaja-kohtaista informaatiota tallennetaan SIM-korttiin. Myös nämä menetelmät perustuvat teleoperaattorien käyttöön.

Tekniikan tason ratkaisujen ongelmana on myös maksun mahdollistavan maksu- tai luottamuskortin hallinnointi koko kortin elinkaaren aikana. Yleisesti kortti aktivoidaan luovutettaessa se asiakkaalle ja suljetaan asiakkaan pyynnöstä tai luottorajan ylittyessä. Aktivoinnin ja sulkemisen väliin jäävä ajanjakso on täysin palveluntarjoajan suhteen hallitsematon, mikä lisää kortin väärinkäytön mahdollisuutta.

Keksinnön tarkoituksena on aikaansaada maksujärjestelmä, joka voidaan toteuttaa tekniikan tason järjestelmiä yksinkertaisemmin ilman teleoperaattoreita ja jolla luottamuskorttia voidaan hallinnoida koko sen elinkaaren ajan. Tämän keksinnön tunnusomaiset piirteet ilmenevät patenttivaatimuksesta 1. Tämä tarkoitus voidaan aikaansaada maksujärjestelmällä sähköisen ja varmistetun maksutiedon tuottamiseksi maksun saajalle, johon maksujärjestelmään kuuluu käyttäjän päätelaite ja toimijan palvelinjärjestelmä, ja jossa maksujärjestelmässä maksusovelluk-sen käyttö on sovitettu kaksivaiheiseksi käsittäen käyttäjän rekisteröitymisen palvelinjärjestelmään ja maksusovelluksen validiteetin ohjauksen käyttöoikeuden avulla käyttäen salausele-menttiä ja ainakin määrävälein palvelinjärjestelmältä saatua maksusovelluksen salaisuutta. Käyttäjän päätelaite käsittää maksusovelluksen maksupyyntöjen muodostamiseksi, luotetun alueen ohjelmallisen salauselementin tallentamista ja käyttöä varten sekä RFID-yhteysvälineet maksutiedon toimittamiseksi maksun saajan päätelaitteeseen. Edelleen käyttäjän päätelaite käsittää yhteysvälineet palvelinjärjestelmään suojattua yhteysprotokollaa käyttäen ja salauselementtiin liittyvät välineet maksusovelluksen käyttöoikeuden ohjaamiseksi päälle ja pois. Toimijan palvelinjärjestelmä käsittää puolestaan hallintasovelluksen päätelaitteen tunnistamiseksi ja hallinnoimiseksi, tietokannan käyttäjäkohtaisia tietoja ja avaimia varten mukaan lukien kunkin maksusovelluksen salaisuuden sekä yhteysvälineet päätelaitteeseen suojattua yhteysprotokollaa käyttäen.

Keksinnön mukaisella maksujärjestelmällä salauselementin eli luottamuskortin tilaa voidaan hallinnoida koko salauselementin elinkaaren ajan, mikä lisää maksujärjestelmän luotettavuutta asiakkaan kannalta. Tästä eteenpäin salauselementistä käytetään nimitystä luottamuskortti.

Edullisesti päätelaitteessa on salauselementin valvoma luottoli-miittilaskuri. Näin voidaan varmistaa että asiakas ei voi ylittää tiettyä ennalta sovittua luottolimiittiä tietyn ajanjakson aikana. Tämä lisää maksujärjestelmän turvallisuutta esimerkiksi tilanteissa, joissa käyttäjän päätelaite on varastettu. Päätelaitteen RFID-yhteysvälineet voivat käsittää NFC-moduulin. NFC-moduulin avulla maksutietojen siirto tapahtuu nopeasti käyttäjän päätelaitteesta.

Erään sovellusmuodon mukaan päätelaitteessa on ohjelmallinen JavaCard-sovellus luotetulla alueella ja sen auktorisoima sovellus turvaamattomalla alueella käyttöliittymän ja palve-linyhteyden muodostamiseksi. JavaCard-sovellus takaa tietoturvan kannalta sensitiivisen datan pysymisen salaisena.

Erään toisen sovellusmuodon mukaan päätelaitteessa on piiritasolla ARM-tekniikalla toteutettu luotettu alue käsittäen Obc -provision system -sovelluksen ja Obc -tulkin ja turvaamattomalla puolella auktorisoidut Obc Credential Manager -sovelluksen, Obc Provision Client -sovelluksen ja Obc tietokannan. Tässä sovellusmuodossa luotetulla alueella olevan informaation määrä on vähäinen, jolloin luotetulta alueelta vaadittava muistikapasiteetti voi olla varsin vähäinen. Salauselementti voi olla toteutettu luotetulla alueella LUA-skriptikielen avulla käyttäen Obc-tulkkia.

Edullisesti päätelaitteeseen kuuluu välittäjäsovellus NFC-moduulin ja OBC Credential Manager -sovelluksen välille. Tulk- kisovelluksen avulla NFC-moduuliin tulevat käskyt voidaan välittää päätelaitetta hallinnoivalle maksusovellukselle.

Maksupyynnön validiteetin ohjaus määrävälein voi olla sovitettu tapahtuvan 2 - 48 h välein, edullisesti joka maksutapahtuman yhteydessä. Näin luottamuskorttia hallinnoidaan jatkuvasti ja voidaan varmistaa, että päätelaitetta käyttävä käyttäjä on oikea henkilö.

Palvelinjärjestelmä on edullisesti sovitettu suorittamaan automaattisen transaktion tarkistuksen jokaiselle maksupyynnölle. Näin palvelinjärjestelmässä ei tarvita erillistä työvoimaa, joka suorittaa tarkistuksen.

Edullisesti palvelinjärjestelmältä saatu maksusovelluksen salaisuus on satunnainen. Tämä lisää tietoturvaa entisestään, sillä yksittäistä salaisuutta voidaan käyttää vain yhteen maksutapahtumaan.

Edullisesti salauselementti on sovitettu asennettavan dynaamisesti ja auktorisoidusti toimijan palvelinjärjestelmästä käyttäjän päätelaitteen luotetulle alueelle rekisteröinnin aikana. Näin voidaan varmistaa, että salauselementti on oikea ja samalla toimitetaan salauselementin tarvittavat avaimet.

Maksupyynnön validiteetti voi olla sovitettu ohjattavan maksusovelluksen PIN-koodin avulla, joka PIN-koodi käsittää yhteisesti maksusovelluksen salaisuuden ja rekisteröintivaiheessa luotavan käyttäjän salaisuuden. Kahden salaisuuden käyttö lisää tietoturvaa kaksisuuntaisesti, sillä näin voidaan varmistua siitä, että sekä käyttäjä että palvelinjärjestelmä ovat oikeita. Tämä puolestaan vähentää käyttäjän ja palvelinjärjestelmän välillä tarvittavaa luottamustarvetta. Käyttäjän päätelaitteen RFID-yhteysvälineet palvelinjärjestelmään voivat olla erillään välineistä maksupyynnön validiteetin ohjaamiseksi. Näin maksun saajan päätelaitteella ei ole missään tapauksessa mahdollisuutta nähdä käyttäjäkohtaisia salaisuuksia.

Erään sovellusmuodon mukaan päätelaitteeseen kuuluva piiritasolla toteutettu luotettu alue on päätelaitteeseen liitetty esivalmistettu SoC-mikropiiri.

Edullisesti maksujärjestelmään kuuluu edelleen maksun saajan päätelaite varustettuna RFID-välineillä, erityisesti NFC-moduu-lilla maksutietojen siirtoa varten. Näin maksutieto voidaan siirtää nopeasti ja langattomasti maksun saajan päätelaitteesta käyttäjän päätelaitteeseen ja edelleen palvelinjärjestelmään tarkistettavaksi. Järjestelmässä kokonaisvaltainen toiminta muodostuu minimaalisesta määrästä toimijoita vähentäen niiden keskinäisestä vuorovaikutuksesta aiheutuvaa riskiä ja luottamuksenhallintaa tehden näin järjestelmästä yksinkertaisen toteuttaa. Toimijoiden vähäinen määrä myös lisää systeemin turvallisuutta ja dynaamisuutta sekä käyttäjälle tarjottavan tapahtumiin liittyvän kontekstin kuten esimerkiksi mainonnan kohdennusta. Tässä esitetty järjestelmä on suunniteltu toimivaksi ympäristössä, jossa käyttäjän hallinnoima päätelaite sisältää RFID-moduu-lin, luotetun alueen sekä toteuttaa RFID-moduulin ja luotetun alueen välisen tämän järjestelmän kannalta edullisen toiminnallisuuden .

Seuraavassa on kuvattu maksujärjestelmän toiminnan esiehtoja. Tässä yhteydessä käytetään termiä luottamuskortti, jolla tarkoitetaan ohjelmallista tunniste- ja salauselementtiä, joka sisältää kyseisessä elementissä ohjelmallisesti luodun salaisen ja julkisen avaimen, sertifikaatin, CA-sertifikaatin, luottamuskor-tin tunnistetiedot (tilinumero, cv-koodi jne, kuten älykorteissa) sekä näitä hallitsevan ja/tai käsittelevän sovelluksen ja sovelluksessa määritellyn kommunikaatioprotokollan toimijan palvelimeen. Maksujärjestelmässä kokonaan uusia osa-alueita ovat sovellus ja kommunikaatioprotokolla sovelluskerroksella sekä sen generoimat avaimet ja sertifikaatit. Järjestelmän toiminnan esiehdot ovat seuraavat:

Toimijalla tarkoitetaan tahoa, joka vastaa kyseessä olevan palvelinjärjestelmän sekä luottamuskortin toiminnasta. Käyttäjän päätelaite sisältää turvallisen luotetun alueen, joka on suojattu älykortteja tai sen kaltaisia käyttäjälle lisäarvoa tuovia digitaalisia hyödykkeitä myöntävien tahojen vaatimusten mukaisilla ja vahvuisilla menetelmillä. Näitä menetelmiä voidaan kutsua myös kredentiaaleiksi. Luotettu alue voi olla virtuaalinen ohjelmiston avulla toteutettu alue tai piiritasolla toteutettu alue. Piiritasolla toteutettu luotettu alue voi olla puolestaan laitevalmistajan, kuten esimerkiksi ARM:n tai Inside Security:n teknologiaa. Luotettu alue voi olla myös SIM-kortti tai osa päätelaitteeseen asetettavaa ulkoista tai sisäistä sirumoduulia. Sirumoduuli voi olla myös osa sisäisesti tai ulkoisesti asetettavaa yhdistemoduulia osana päätelaitetta. Yhdistemoduulilla tarkoitetaan mikropiirien yhdistelmää, jossa on integroitu esimerkiksi WLAN, BT/NFC samaan mikropiiriin . Tässä dokumentissa luottamuskortilla tarkoitetaan päätelaitteen käyttöjärjestelmän luotetulle alueelle tai päätelaitteeseen lisätyn lisälaitteen luotetulle alueelle tai muulle toimijalle varatulle ja identifioidulle turvalliselle muistialueelle tallennettua virtuaalista luottamuskorttia, joka käytöltään vastaa perinteistä pankki- tai luottokorttia. Luottamus-kortti sisältää sensitiivistä tietoa sekä joukon turvaominaisuuksia ja primitiivejä, joilla sallitut tahot voivat kommunikoida sen kanssa. Yksinkertaistettuna luottamuskortti on maksusovelluksen käyttöoikeutta hallitseva sovellus, joka sisältää maksusovelluksen salaukseen tarvittavat avaimet ja sertifikaatit, salausalgoritmin sekä mahdollisesti myös luotto-limiitin. Tässä maksujärjestelmässä sensitiivistä tietoa ovat PIN--koodit, avaimet, varmenteet sekä kaikki muu toimijan määrittelemä arkaluontoinen maksujärjestelmään suoraan tai välillisesti liittyvä tieto.

Luottamuskortin käyttö edellyttää niin sanotun jaetun salaisuuden ratkaisemista käyttäjän ja palvelinjärjestelmän välillä, jotta luottamuskorttia voidaan käyttää. Jaettu salaisuus (PIN-koodi) on yhdistelmä käyttäjän tietämästä salaisuudesta sekä palvelinjärjestelmään tallennetusta toimijan määrittelemästä määräajoin vaihtuvasta salaisuudesta.

Luottamuskortti identifioidaan yksilöllisellä luottamus-kortin tunnisteella tai siitä johdettavalla yksilöivällä arvolla .

Luottamuskortti kommunikoi aina luotettavasti ja turvallisesti Internetiin tai muun median yli siihen sidotun palvelinjärjestelmän, kolmannen osapuolen omistaman järjestelmän, luottamuskortin, toisen luottamuskortin tai ulkoisen kontaktit-toman maksamisen toiminnallisuutta tukevan lukijan kanssa.

Luotettava kommunikointi toteutetaan edullisesti vähintään 2-suuntaisen SSL/TLS -protokollan vahvuisella turvamekanismilla käyttäen optimoidun kokoisia avaimia suhteessa käytettävissä olevaan laskentatehoon, käytettävyyteen ja operaatioiden vaatimiin yksilöllisiin turvallisuusvaatimuksiin. Vaihtoehtoisesti kaikki luotetun alueen ulkopuolinen tietoliikenne salataan luotetulla alueella olevalla salausalgoritmillä käyttäen luotetun alueen salausavaimia.

Luottamuskortti hakee kaiken toiminnallisuuteen tarvittavan tiedon dynaamisesti siihen sidotusta palvelinjärjestelmästä.

Luottamuskortti toimii ainoastaan toimijan palvelinjärjestelmän kanssa.

Toimijan palvelinjärjestelmä vastaa luottamuskortin turvallisuudesta ja hallinnoimisesta. Käyttäjällä tarkoitetaan henkilöä, joka toimii vuorovaikutuksessa päätelaitteen sekä luottamuskortin kanssa. Luottamus-kortin käyttö edellyttää käyttäjän, luottamuskortin sekä palve- limen auktorisoitua tunnistamista toimijan järjestelmän toimesta. Käyttäjällä on käytössään RFID-teknologiaa tukeva päätelaite, jolla on mahdollista muodostaa yhteys Internet:iin tai muuhun mediaan.

Palvelinjärjestelmä on liitetty Internet:iin tai muuhun mediaan.

Palvelinjärjestelmä sisältää turvallisen luotetun alueen, johon sensitiivinen luottamuskorttien alustukseen käytettävä tieto varastoidaan.

Keksintöä kuvataan seuraavassa yksityiskohtaisesti viittaamalla oheisiin eräitä keksinnön sovelluksia kuvaaviin piirroksiin, joissa

Kuva 1 esittää keksinnön mukaisen maksujärjestelmän yleiskuvauksen,

Kuva 2 esittää keksinnön mukaisen maksujärjestelmän luottamuskortin rekisteröinnin lohkokaaviona, Kuva 3 esittää keksinnön mukaisen maksujärjestelmän erään sovellusmuodon maksutapahtuman lohkokaaviona,

Kuva 4 esittää keksinnön mukaisen maksujärjestelmän erään toisen sovellusmuodon maksutapahtuman lohkokaaviona,

Kuva 5 esittää tekniikan tason mukaisen maksujärjestel män arkkitehtuurikuvauksen,

Kuva 6 esittää erään sovellusmuodon mukaisen JAVA Card arkkitehtuurikuvauksen,

Kuva 7 esittää erään toisen sovellusmuodon mukaisen

TrustZone ja Obc -arkkitehtuurikuvauksen. Tässä yhteydessä maksusovelluksella tarkoitetaan kaikkia päätelaitteen sekä luotetulla alueella että turvaamattomalla alueella olevia ohjelmistokomponentteja, jotka yhdessä hyväksikäyttävät luotetulla alueella olevia salauselementin tietoja ja avaimia sekä RFID-välineitä ja yhteysvälineitä. Edelleen yhteysvälineil lä tarkoitetaan niitä ohjelmistokomponentteja, jotka hoitavat Internet-yhteyden kautta kommunikaatiota palvelinjärjestelmään päin. Kuvissa 1 - 4 ja taulukoissa la - 2b luottamuskortista käytetään yhteistä nimitystä Trust Card.

Kuvan 1 mukaisesti keksinnön mukainen maksujärjestelmä muodostuu käyttäjän hallinnoimasta päätelaitteesta 62,84 sekä toimijan palvelinjärjestelmästä 68,85 sekä niihin liittyvistä tässä kuvauksessa esitetyistä kokonaisuuksista. Järjestelmä tukee autonomisia kontaktittomia maksutapahtumia, jossa käyttäjä voi suorittaa maksutapahtuman RFID-teknologiaa tukevan päätelaiteensa 62,84, ja erityisesti sen maksusovelluksen kautta. Jokaiselle järjestelmän käyttäjälle asennetaan personoitu kopio palvelinjärjestelmään 68,85 tallennetusta luottamuskortista 100 tai vaihtoehtoisesti jokaisella käyttäjällä on oma rinnakkais-luottamuskortti palvelinjärjestelmässä, joka asennetaan dynaamisesti käyttäjän päätelaitteeseen. Molemmissa tapauksissa korttiin liitetyn tilin omistaja on toimija, jolloin järjestelmän toiminnallisuus säilyy molemmissa tapauksissa samana. Toimijan palvelinjärjestelmä 68,85 vastaa päätelaitteeseen 62,84 siirrettävän luottamuskortin 100 koko elinkaaresta kuten asennuksesta, päivityksestä, personoinnista, mitätöimisestä ja tuhoamisesta. Tällöin kokonaissysteemin, maksutapahtuman sekä näihin liittyvän toiminnallisuuden riskien ja kustannuksia aiheuttavien osapuolten määrä saadaan minimoitua. Järjestelmässä ulkoinen päätelaite eli RFID-lukija 67,81 on kauppiaalla ja päätelaite 62,84 asiakkaalla. Jatkossa ulkoisesta RFID-lukijasta käytetään nimitystä ulkoinen lukija. Päätelaite on edullisesti matkapuhelin, mutta se voi olla myös tabletti, digitaalinen rannelaite, kannettava tietokone tai mikä tahansa vastaava näytöllä ja käyttöliittymällä varustettu laite, johon voidaan lisätä RFID. Keksinnön mukaisessa järjestelmässä asiakkaan 102 tunnistamiseen liittyvä tietoliikenne tapahtuu asiakkaan 102 päätelaitteen 62,84 kautta. Ensin tunnistautuminen tehdään päätelaitteen 62,84 kautta palvelinjärjestelmässä 68,85 ja tulos palautetaan takaisin päätelaitteeseen 62,84. Kauppiaan ulkoinen lukija 67,81 sitten tarkistaa tuon tuloksen luottamus-kortista 100 esimerkiksi NFC-protokollan mukaisesti. Tulosta ei voi väärentää turvaluokituksen ja/tai luotetun alueen ansiosta. Jos tulos on ok, kauppa hyväksytään sellaisenaan, mikäli kauppiaan ulkoinen lukija 67,81 hyväksyy offline-tarkistukset mobiili-maksamisen kanssa. Vaihtoehtoisesti ulkoinen lukija 67,81 lähettää tarkistuksen tuloksen edelleen pankille 104, jos kauppias niin haluaa. Järjestelmää voidaan käyttää ilman tätä vaihetta varsinkin, jos toimija on kortinmyöntäjä.

Seuraavaksi on selitetty kuvan 2 avulla käyttäjän rekisteröinti maksujärjestelmään. Lähtökohtaisesti käyttäjän päätelaite sisältää siihen sen laitevalmistajan toimesta kovakoodaamat CA-varmenteet, salausalgoritmin, julkisen avaimen PK1 ja salaisen avaimen SK1 yleistä salausta ja tunnistautumista varten. Käyttäjä lataa palvelinjärjestelmän sovelluksen maksujärjestelmän määrittämästä paikasta, aukaisee sen käyttämässään päätelaitteessa ja tunnistautuu sovellukseen esimerkiksi TUPAS-palvelua tai vastaavaa virallista tunnistautumispalvelua käyttäen. Käyttäjälle annetaan näkymä rekisteröinnistä maksujärjestelmän palveluun ja käyttäjän täydentämät tiedot lähetetään verifioituna palvelinjärjestelmään vaiheessa 1. Käyttäjän antamat tiedot saapuvat palvelinjärjestelmään, jossa käyttäjän henkilöllisyys ja luottokelpoisuus tarkistetaan rekisteröinnin vaiheessa 2. Rekisteröinnissä käyttäjä luo itselleen käyttäjän salaisuuden eli salasanan SS1, josta tallennetaan palvelinjärjestelmään vain tiiviste. Rekisteröinnin onnistuminen tarkistetaan vaiheessa 3. Jos käyttäjän tiedot todetaan kelvollisiksi, tallennetaan tiedot palvelinjärjestelmään ja rekisteröintiprosessi päätetään. Epäonnistuneessa tilanteessa rekisteröintiprosessi kumotaan, käyttäjän antamat tiedot poistetaan ja käyttäjälle luodaan näkymä epäonnistuneesta rekisteröinnistä vaiheessa 4.

Onnistunutta rekisteröintiprosessia jatketaan palvelinjärjestelmässä käyttäjän yksilöivän tiedon luomiseksi sekä lähetetään allekirjoitettu tulos onnistuneesta rekisteröinnistä käyttäjän päätelaitteelle. Edelleen palvelinjärjestelmän sovellus pyytää luotetulta alueelta tarjotun kutsurajapinnan kautta päätelaitteeseen sen valmistusvaiheessa liitetyn ja varmennetun julkisen avaimen PK1 sekä lähettää sen palvelinjärjestelmään vaiheessa 5. Palvelinjärjestelmä luo symmetrisen salausavaimen SYKI, jonka se salaa päätelaitteelta saadulla julkisella avaimella PKS1 ja lähettää takaisin käyttäjän päätelaitteelle vaiheessa 6. Päätelaitteessa symmetrinen salattu avain SYKI toimitetaan luotetulle alueelle tarjotun kutsurajapinnan kautta ja puretaan siellä päätelaitteen yksityisellä avaimella SK1, jonka jälkeen symmetrinen salattu avain tallennetaan vaiheessa 7.

Palvelinjärjestelmä lähettää seuraavaksi maksusovelluksen, siihen liittyvän sensitiivisen tiedon eli palvelinjärjestelmän luottamuskorttikohtaisen salaisuuden SS2 sekä palvelinjärjestelmän julkisen avaimen PK2 symmetrisellä avaimella SYKI salattuna päätelaitteelle vaiheessa 8. Vaiheessa 9 palvelinjärjestelmän lähettämä paketti puretaan palvelinjärjestelmän luomaa symmetristä avainta SYKI käyttäen. Käyttäjälle yksilöity luottamus-kortti sekä palvelinjärjestelmän salaisuus SS2 tallennetaan päätelaitteessa luotetulle alueelle tarjotun kutsurajapinnan kautta. Samalla asetetaan päätelaitteen PIN-koodi, joka muodostuu käyttäjän valitsemasta salasanasta SSl ja palvelinjärjestelmän salaisuudesta SS2. Julkisella avaimella tarkoitetaan tässä yhteydessä epäsymmetriseen RSA-salausalgoritmiin liittyvää julkista avainta.

Keksinnön mukaisessa maksujärjestelmässä luotetun alueen muistin koosta riippuen sensitiivinen data voidaan tallentaa suoraan luotetulle alueelle tai vaihtoehtoisesti sensitiivinen data voidaan ainoastaan salata luotetulla alueella. Tällöin salauksen jälkeen salattu sensitiivinen data voidaan tallentaa luotetun alueen ulkopuolelle mihin tahansa turvaamattomalle päätelaitteen muistialueelle. Joka tapauksessa luotetulle alueelle on tallennettu salausalgoritmi ja sen avaimet. Sensitiivisen datan ollessa salattuna luotetun alueen ulkopuolella maksusovellus käyttää luotetulle alueelle tallennettuja avaimia kaikkien datalähetyksien salaamiseen ja avaamiseen. PIN-koodin muodostuksen jälkeen luodaan käyttäjän luottamuskort-tiin yksityinen avain SK3 ja lähetetään sertitikaattipyyntö palvelinjärjestelmään identiteetin kanssa symmetrisellä avaimella SYKI salattuna ja turvallista mediaa käyttäen vaiheessa 10. Palvelinjärjestelmässä salaus puretaan käyttäen palvelinjärjestelmän yksityistä avainta SK2 ja sertifikaatti allekirjoitetaan palvelinjärjestelmän CA-varmenteella vaiheessa 11. Tämän jälkeen allekirjoitettu CA-varmenne salataan jälleen symmetristä avainta SYKI käyttäen. Lopuksi allekirjoitettu luottamuskortin sertifikaatti Cl lähetetään salattua ja turvallista mediaa pitkin käyttäjän päätelaitteelle, käyttäjälle spesifioituun luottamus-korttiin vaiheessa 12. Vaiheessa 13 allekirjoitettu luottamus-kortin sertifikaatti Cl puretaan avaimella SYKI ja tallennetaan luotetulle alueelle. Sertifikaatti Cl sisältää myös julkisen avaimen PK3 . Allekirjoitettu luottamuskortin sertifikaatti Cl ja julkinen avain PK3 tallennetaan myös palvelinjärjestelmään myöhempiä käyttötapauksia varten. Lopuksi luodaan näkymä käyttäjälle onnistuneesta rekisteröinnin lopputuloksesta vaiheessa 14 ja annetaan käyttäjälle mahdollisuus kirjautua toimijan palvelinjärjestelmään sisään.

Seuraavaksi on selitetty kuvan 3 avulla maksutapahtuman suorittaminen keksinnön mukaisessa maksujärjestelmässä. Lähtötilanteessa käyttäjällä on tiedossaan salasana SS1, palvelinjärjestelmällä on salaisuus SS2 ja julkinen avain PK3 ja päätelaitteeseen on tallennettu allekirjoitettu sertifikaatti Cl ja julkinen avain PK3. Kauppias syöttää maksutapahtuman tiedot ulkoiselle kontaktittoman luottamuskortin lukijalle vaiheessa 15, joka tukee RFID-teknologiaa. Käyttäjä avaa päätelaitteellaan mak-susovelluksen ja aktivoi luottamuskortin maksusovelluksen tähän tarkoitettua erityistä painiketta käyttäen vaiheessa 16. Tämän tuloksena käyttäjälle annetaan sisäänkirjautumisikkuna, jossa käyttäjältä pyydetään salasana SSI(check) vaiheessa 17. Syötteiden tiivisteet lähetetään salattuna ja turvallista mediaa käyttäen palvelinjärjestelmälle, joka prosessoi saadut tiedot tehokkaasti vaiheessa 18. Samalla syötetty salasana SSI(check) välitetään myös päätelaitteen luotetulle alueelle ja tarkistetaan siellä. Mikäli kirjautuminen epäonnistuu, käynnistetään varmennemekanismi päätelaitteessa vaiheessa 19, joka sisältää prosessointiohjeet kuinka virhetilanteessa menetellään, kuten esimerkiksi virheellisten syöttöjen sallittu lukumäärä, ennen kuin luottamuskortti asetetaan toimintakelvottomaksi. Tällöin käyttäjä voi saada uuden kortin ainoastaan rekisteröitymällä uudestaan järjestelmään. Kirjautumisen onnistuessa vaiheessa 20 palvelinjärjestelmä valitsee sen luotetulta alueelta satunnaisen symmetrisen avaimen SYK2 ja lähettää sen käyttäjän päätelaitteelle luottamuskortin julkisella avaimella PK3 salattuna.

Vaiheessa 21 päätelaite vastaanottaa paketin palvelinjärjestelmältä ja purkaa salauksen julkisella avaimella PK3. Tämän jälkeen avain SYK2 tallennetaan luotetulle alueelle, mikä aktivoi luottamuskortin sen sisäisen tilakoneen avulla. Vasta tämän jälkeen luottamuskortti voi kommunikoida muiden tahojen, kuin palvelinjärjestelmän kanssa. Ulkoisen lukijan ollessa kommunikoivana osapuolena, luottamuskortti toimii aina passiivisessa tilassa, mutta ilman edellä mainittua aktivointia luottamuskortti ei reagoi ulkoisen lukijan tai minkään muun toisen aktiivisen tai passiivisen RFID-yhteensopivan päätelaitteen yhteydenmuodostus pyyntöön suoraan tai RFID-moduulin kautta. Toisaalta eräässä toisessa sovellusmuodossa luottamuskortti voi toimia aktiivisena kuten kuvassa 6, mutta toiminta edelleen edellyttää ajoittaista vuorovaikutusta toimijan palvelimen kanssa.

Aktivoinnin jälkeen käyttäjälle annetaan näkymä päätelaitteen siirtämiseksi ulkoisen lukijan läheisyyteen vaiheissa 22 ja käyttäjä vie päätelaitteen ulkoisen lukijan läheisyyteen vaiheessa 23, joka ulkoinen lukija lukee automaattisesti tarvitta- vat luottamuskortin tiedot päätelaitteen luotetulta alueelta vaiheessa 24. Ulkoinen lukija palauttaa päätelaitteelle maksutapahtuman tiedot, jotka siirretään automaattisesti päätelaitteeseen luotetulle alueelle RFID-moduulin toimesta. Päätelaitteelta maksutapahtuman tiedot lähetetään avaimella SYK2 salattuna palvelinjärjestelmään prosessoitavaksi ja tallennettavaksi vaiheessa 26. Tästä annetaan käyttäjälle prosessointinäkymä vaiheessa 25. Palvelinjärjestelmä purkaa maksutietolähetyksen avaimella SYK2 ja suorittaa automaattisen tarkistuksen onko asiakas oikeutettu tapahtumaan vaiheessa 27. Jos varmistus epäonnistuu, keskeytetään ja annetaan käyttäjälle näkymä epäonnistumisen syystä vaiheessa 28. Lisäksi toimijan automaattinen varmennemekanismi tarkistaa, mikä tarkistuksessa epäonnistui ja käsittelee tilanteen sen mukaisesti. Esimerkiksi jos virhe todetaan erittäin vakavaksi kuten kortin luvattomaksi käytöksi tai varastettu listalla olevaksi, luottamuskortti mitätöidään.

Jos maksutapahtuma hyväksytään palvelimen varmistusjärjestelmän toimesta, lähetetään päätelaitteelle avaimella SYK2 salattuna palvelinjärjestelmään tallennettu ja kyseenomaiseen luottamus-kortin identiteettiin sidottu ja sen toimintaan tarvittava palvelinjärjestelmän salaisuus SS2(check) vaiheessa 29. Vaiheessa 30 päätelaitteessa vastaanottava asiakassovellus välittää viestin edelleen luottamuskortille, jossa salaus puretaan avaimella SYK2. Palvelinjärjestelmän salaisuus SS2(check) ja käyttäjän salasana SSI(check) yhdistetään PIN(check):ksi ja arvo syötetään päätelaitteella olevan luottamuskortin sisäiseen tilakoneeseen. Edelleen vaiheessa 31 käyttäjälle annetaan näkymä päätelaitteen viemiseksi RFID-lukijan läheisyyteen, jolloin PIN(check) tarkistetaan vertaamalla sitä rekisteröintivaiheessa luotuun PIN:iin, joka muodostuu salaisuuksista SS1 ja SS2. Tarkistuksen onnistuminen mahdollistaa middlewaren eli välittä-jäsovelluksen kommunikoinnin NFC-moduulin kanssa.

Yleisesti ottaen rekisteröintivaiheessa luodaan todelliset SS1, SS2 ja näistä PIN, jotka tallennetaan esimerkiksi luotetulle alueelle tai muualle päätelaitteen muistiin salattuina symmetrisellä avaimella. Maksutapahtuman yhteydessä käyttäjä antaa SSI(check):n ja palvelinjärjestelmä SS2(check):n, joista luodaan PIN(check). Näin voidaan varmistua, että maksutapahtuman yhteydessä sekä käyttäjä on päätelaitteen todellinen käyttäjä, joka tietää rekisteröintivaiheen SSl:n ja myös palvelin on todellinen palvelin, joka tietää rekisteröintivaiheen SS2:n. PIN-koodi on siis hajautettu käyttäjän ja palvelimen kesken, jolloin tarvitaan kaksiosainen autentikointi molempien osapuolien identiteetin varmistamiseksi. Käyttäjä ei missään vaiheessa tiedä päätelaitteen todellista PIN-koodia. Luottamuskortin sisäisen tilakoneen aktivointi tapahtuu vertaamalla PIN(check):ä todelliseen PIN:n ja jos ne vastaavat toisiaan, sisäinen tilakone aktivoituu.

Vaiheessa 32 asiakas vie RFID-yhteysvälineillä varustetun päätelaitteen ulkoisen lukijan lähelle. Ulkoinen lukija lukee luotetulta alueelta luottamuskortin tiedot sekä PIN-koodin tarkistuksen tuloksen vaiheessa 33. Tiedot välitetään eteenpäin palvelinjärjestelmän alkuperäisen luottamuskortin myöntäjälle vaiheessa 34, joka palauttaa vastauksen takaisin kauppatapahtumaan osallistuvalle ulkoiselle maksupäätteelle. Ulkoinen lukija voi tehdä myös offline-tarkistuksen vaiheessa 34, jolloin päätelaitteelta luettu ja hyväksytty PIN-koodin tarkistus tulos johtaa maksutapahtuman hyväksymiseen kauppiaan järjestelmään ja asiakkaalle tulostetaan tapahtumaa vastaava kuitti ulkoiselta lukijalta vaiheessa 37. Maksutapahtuman tiedot lähetetään automaattisesti ulkoisen lukijan toimesta myös luottamuskorttiin vaiheessa 35 ja edelleen palvelimelle vaiheessa 40. Tämän jälkeen käyttäjälle ilmoitetaan tapahtuman päättymisestä ja päätelaite voidaan poistaa maksupäätteen läheisyydestä vaiheessa 36. Jos tarkistus vaiheessa 34 epäonnistuu, lähetetään maksutapahtuman tiedot salattuna palvelinjärjestelmään vaiheessa 38. Palvelinjärjestelmä merkitsee vaiheen 27 tapahtuman epäonnistuneeksi vaiheessa 39. Lopuksi ilmoitetaan käyttäjälle transaktion epäonnistumisesta ja maksutapahtuma lopetetaan.

Maksutapahtuma voidaan suorittaa myös toista sovellusmuotoa käyttäen kuvan 4 mukaisesti. Maksujärjestelmän toinen sovellus-muoto mahdollistaa maksutapahtuman suorittamisen ilman välitöntä toimijan palvelimen kanssa kommunikointia. Tässä sovellusmuodos-sa toimijan palvelin sisältää yleiset tai käyttäjäkohtaiset määräykset siitä, kuinka usein käyttäjän on suoritettava toimijan määrittämä tunnistautuminen, luottamuskortin tilan ja tapahtumien tarkistus sekä synkronointi palvelinjärjestelmän kanssa. Tällöin luottamuskortti voi toimia ja sillä voidaan suorittaa maksutapahtumia itsenäisesti ilman toimijan palvelinjärjestelmän auktorisointia, kunnes määritetty aikaraja täyttyy tai luottamuskortille tallennettu käyttöraja tulee vastaan. Molemmista tapahtumista maksusovellus ilmoittaa käyttäjälle ennen käyttöäjanjakson tai saldorajan loppumista. Käyttäjä voi halutessaan suorittaa uuden aktivoinnin milloin vain ennen määräajan umpeutumista tai sen jälkeen, jolloin luottamuskorttia ei voi käyttää ennen uutta aktivointia.

Uusi aktivointi voidaan tehdä kuvan 4 mukaisesti kirjautumalla päätelaitteella toimijan järjestelmään vaiheissa 42 - 45 kuten kuvan 3 ensimmäisessä sovellusmuodossa on esitetty. Edelleen palvelinjärjestelmä salaa kyseisen käyttäjän päätelaitteen luottamuskortin varmenteella maksulimiitin, luottamuskortin voimassaoloajan sekä toimijan salaisuuden vaiheessa 46. Tässä luottamuskortin voimassaoloaika tarkoittaa toimijan määrittelemää turvakäytäntöä, koska luottamuskortin uudelleen aktivointi palvelimen toimesta on tehtävä, jotta sitä voisi taas käyttää. Esimerkkinä voimassaoloajasta voi olla yksi vuorokausi. Tämän jälkeen salatut tiedot lähetetään päätelaitteelle vaiheessa 46, jossa ne siirretään luotetulle alueelle ja tallennetaan vaiheessa 47 .

Vaiheessa 48 maksutapahtuma aktivoidaan käynnistämällä asianomainen sovellus ja viemällä päätelaite ulkoisen lukijan läheisyyteen vaiheessa 49. Toisaalta maksutapahtuman aktivointi voidaan tehdä myös ilman sovelluksen käynnistämistä, jolloin sovellus käynnistetään ulkoisen lukijan vaikutuksesta. Ulkoinen lukija hakee luottamuskortin tiedot luotetulta alueelta vaiheessa 50 ja käyttäjän päätelaitteella annetaan näkymä maksutapahtuman tiedoista vaiheessa 51. Vaiheessa 52 käyttäjä syöttää salasanan SS1 päätelaitteeseen ja vie sen uudelleen ulkoisen lukijan läheisyyteen kuittaukseksi vaiheessa 53. Ulkoinen lukija hakee luottamuskortin PIN-koodin tarkistuksen tuloksen vaiheessa 54 ja prosessoi tapahtuman vaiheessa 55. Edelleen ulkoinen lukija lähettää tiedot maksutapahtumasta luottamuskortille, joka vaiheessa 56 tallentaa ne luotetulle alueelle sekä muuttaa jäljellä olevaa saldoa tapahtuman mukaisesti. Tästä annetaan käyttäjälle vastaava näkymä vaiheessa 57. Vaiheet 50 - 54 voidaan eräässä sovellusmuodossa yhdistellä, niin että salasana SS1 annetaan ensin joko päätelaitteelle tai ulkoiselle lukijalle, jonka jälkeen viedään päätelaite ulkoisen lukijan läheisyyteen. Tätä seuraa suoraan hyväksyntä tai hylkäys, jonka tulos tallennetaan vastaavasti päätelaitteelle vaiheessa 56 ja annetaan käyttäjälle näkymä maksutapahtumasta vaiheessa 57.

Kun toimijan turvakäytännön mukainen kortin voimassaoloaika on päättymässä esimerkiksi yhden vuorokauden kuluttua edellisestä aktivoinnista, annetaan vaiheen 58 mukaisesti käyttäjälle siitä näkymä, jossa käyttäjää pyydetään aktivoimaan luottamuskortti ennen seuraavaa käyttöä. Edelleen päätelaite salaa ja lisää todennuksen maksutapahtumat sisältävään lokitiedostoon vaiheessa 59, jotka siirretään päätelaitteen luotetulta alueelta palvelinjärjestelmään vaiheessa 60 turvallisen yhteyden yli ja tallennetaan vaiheessa 61. Vastaavasti luottamuskortille sekä käyttäjälle suoritetaan tarkistus kuvan 3 vaiheessa 27 ja aktivoidaan luottamuskortti uudelleen kuvan 4 vaiheiden 44 - 47 avulla.

Molemmissa edellä esitetyissä sovellusmuodoissa rahan tilitys kauppiaalle voidaan suorittaa vastaavasti kuin perinteisissä luottokorttijärjestelmissä. Kauppias lähettää onnistuneen maksutapahtuman tiedot pakettina pankkiin tai luottoyhtiölle tilitystä varten. Maksutapahtuman tietojen perusteella pankki tai luottoyhtiö tilittää rahat kauppiaalle. Tätä vaihetta ei ole kuvattu kuvassa 3, mutta se tulee ymmärtää luonnolliseksi osaksi j ärj estelmää.

Keksinnön mukaisen maksujärjestelmän yhteydessä käytetään RFID:tä (Radio Frequency IDentification) eli radiotaajuista etätunnistusta maksutiedon toimittamiseksi maksun saajalle eli kauppiaalle. RFID on menetelmä tiedon etälukuun ja -tallentamiseen käyttäen RFID-tunnisteita, eli tageja. Edullisesti keksinnön mukaisessa järjestelmässä käytetään RFID:nä sen erityistä sovellusta NFC:tä. Tässä yhteydessä NFC:llä eli Near Field Communication tarkoitetaan RFID:hen pohjautuva radiotaajuisen etätunnistuksen hyvin lyhyillä, korkeintaan muutamien senttimetrien, etäisyyksillä mahdollistavaa tekniikkaa. Suurin ero tavallisiin RFID-tägeihin on se, että NFC-laite voi toimia sekä lukijalaitteena että tunnisteena, toisin kuin perinteiset RFID-laitteet. NFC:tä voidaan käyttää matkapuhelinten yhteydessä liittämällä puhelimiin NFC-ominaisuudet. NFC on mahdollista saada puhelimiin jälkiasennettuna myös erityisten SIM- tai microSD-korttien avulla. NFC-yhteys perustuu sähkömagneettiken-tän induktioon radiotaajuudella 13,56 MHz. Tiedonsiirtonopeus voi olla 106, 212 tai 424 kbit/s, jotka soveltuvat pienten tietomäärien siirtoon. Suurempia tietomääriä käsiteltäessä NFC:tä voi käyttää avaamaan yhteys, jossa varsinainen tiedonsiirto hoidetaan esimerkiksi Bluetooth:11a. NFC:tä käytetään järjestelmässä ainoastaan päätelaitteen ja kauppiaan lukijan väliseen kommunikointiin NFC forum standardien mukaisesti. Maksusovellus huolehtii siitä, että ulkoiselle lukijalle tarjotaan APDU-yhteyden (APDU = application protocol data unit) kautta tarvittavat pankkitiedot ja auktorisoinnin tulos. Lisäksi käytettäessä termiä RFID tai NFC voi olla myös WLAN (Wireless Local Area Network), jolloin maksupääte voi olla kaukana maksavasta asiakkaasta, kun se NFC:llä on noin 5 cm etäisyydellä. Molemmat ovat jo standardoituja yhteysmuotoja. WLAN:ia voidaan käyttää esimerkiksi seuraavasti. Asiakas tulee kauppaan ja aktivoi NFC:n avulla luottamuskortin palveluntarjoajan palvelun päälle. NFC menee kuuntelu tilaan ja samalla WLAN aktivoidaan. Tämä on mahdollista tehdä NFC-standardissa, kuin myös Bluetooth:n aktivoiminen. Asiakas lähtee kiertämään kauppaa ja ostaa ostoksia sitten, että käyttää NFC poster -siruja hyväkseen, joita kauppias käyttää hintalapuissaan. Käyttäjä vilauttaa hintalapun päällä päätelaitettaan, jossa on aktiivisessa tilassa oleva NFC-siru, ja hinta ja/tai määrä menee APDU-protokollan yli päätelaitteelle palveluntarjoajan järjestelmään. Kun asiakas on tehnyt ostoksensa, hän voi maksaa ostoksensa suoraan WLAN:n yli tai sitten suoraan NFC:n yli keksinnön mukaisella järjestelmällä. NFC:n yli maksettaessa kauppiaalla tulee olla ulkoinen NFC-lukija ja WLAN tapauksessa kauppiaan tulee tarjota WLAN-verkko kaupan sisällä.

Maksun saajan eli kauppiaan ulkoisen NFC-lukijan maksutapahtumassa käyttäjän päätelaitteelle esittämät APDU-komennot on esitetty selitysosan lopussa. Selitysosan loppuun on myös sijoitettu taulukot la - 2b, joissa taulukoissa la ja Ib on esitetty kuvan 3 maksutapahtumassa käytettävät muuttujat ja niiden arvot eri vaiheissa maksutapahtumaa. Taulukoissa la ja Ib esitetty TZ-arvo vastaa kuvien 2 ja 3 vaiheita. Vastaavasti taulukoissa 2a ja 2b on esitetty kuvan 4 verkkoyhteydettömässä maksutapahtumassa käytettävät muuttujat ja niiden arvot eri vaiheissa maksutapahtumaa. Taulukoissa 2a ja 2b esitetty TZ-arvo vastaa kuvien 2 ja 4 vaiheita.

Kuvassa 5 on esitetty tekniikan tasoa edustavan järjestelmän kuvaus. Kuvan mukaisesti päätelaitteessa on luotettu alue, jonne sensitiivistä dataa on tallennettu. Kaikki liikenne päätelaitteen ja palvelinjärjestelmän välillä tapahtuu teleoperaattorin kautta. Teleoperaattorin käyttö lisää järjestelmän monimutkaisuutta ja tietoturvamurron riskiä ylimääräisenä vaiheena prosessissa. Suurimpana ongelmana on kuitenkin se, että teleoperaatto-rivetoisissa järjestelmissä palvelinjärjestelmän salaisuus toimitetaan käyttäjän päätelaitteeseen vain rekisteröinnin tai aktivoinnin yhteydessä. Tämän jälkeen päätelaitteen luottamus-korttia ei hallinnoida mitenkään maksutapahtumien yhteydessä. Ainoastaan luottamuskortin sulkeminen esimerkiksi luottamuskor-tin väärinkäytön yhteydessä on teleoperaattorin hallinnollinen toimenpide. Käyttäjän maksutapahtuma edellyttää keksinnön mukaisissa järjestelmissä yleensä ainoastaan yhden PIN-koodin, jolla käyttäjä vahvistaa maksun.

Seuraavaksi on selitetty kuvien 6 ja 7 avulla keksinnön mukaisen maksujärjestelmän kahteen erilaiseen arkkitehtuuriseen ratkaisuun perustuvien sovellusmuotojen korkean tason arkkitehtuurikuvaus maksujärjestelmän olennaisten piirteiden osalta. Kuvien 6 ja 7 katkoviivoin esitetyt entiteetit kuvaavat toimijan järjestelmän omistamia ja kehittämiä sovellus ja järjestelmä ratkaisuja, kun taas ehjin viivoin esitetyt entiteetit ovat muissa standardeissa ja spesifikaatioissa kuvattuja osakokonaisuuksia. Vastaavasti katkoviivoin esitetyt kommunikointisekvenssit kuvaavat toimijan omiin ratkaisuihin perustuvia menetelmiä ja toteutustapoja, kun taas ehjin viivoin esitetyt sekvenssit kuvaavat muissa eri standardeissa määriteltyjä ratkaisuja, jotka toimija on valinnut teollisessa sekä teknisessä mielessä edullisesti. Käyttäjän päätelaite sisältää päätelaitteeseen laitevalmistajan tai sen sidosryhmän toimesta esiasennetun luotetun alueen. Luotettu alue voi olla päätelaitteeseen valmistusvaiheessa luotu, SIM-kortille tai ulkoiselle muistikortille sijoitettu alue tai ohjelmallisesti luotu virtuaalinen alue. Luotettu alue toimii päätelaitteissa yleisesti TEE (Trusted Execution Environment) -alueella, kyseistä luotettua aluetta on myös kutsuttu Tree -lyhenteellä. Esimerkkitilanteissa käytetään TEE -nimitystä. TEE-alueen turvaluokitus on varmistettu erityisen vahvalla ja turvallisella salausmenetelmällä. Yleensä tämä tarkoittaa sitä, että TEE:n eheys turvallisuuden näkökannasta tarkistetaan päätelaitevalmistajan toimesta tuotantovaiheessa salatulle alueella integroidulla salatulla merkkijonolla. Tällaisia salattuja alueita on esimerkiksi eFuse, joka perustuu IBM-teknologiaan. Merkkijonoa ei voi muuttaa tai lukea salatulla alueella toimivan sovelluksen toimesta suorituksen aikana. Kyseistä prosessia kutsutaan salatuksi käynnistyssekvenssiksi. TEE -ympäristölle on tunnusomaista, että samassa päätelaitteessa pystytään suorittamaan eristetyn turva-alueen rajoittamien toimien lisäksi myös turvaamattoman alueen toimintoja saman käynnistyssekvenssin aikana. Luotetulle alueelle voidaan tallentaa salaista ja pysyvää tietoa, joka pysyy salassa ja eheässä tilassa. TEE -ympäristön eheys pystytään tarkistamaan tarvittaessa. Turvaamaton alue voidaan muodostaa mille tahansa käyttöjärjestelmän alustalle, esimerkiksi Symbian:lle. Turvaamattomalla alueella käytetään konekieliseksi käännettyä ohjelmakieltä, joka voi olla esimerkiksi QML/QT/C++ tai HTML5. Turvaamattomalla alueella liikkuva data on luotetun alueen luottamuskortin salaamaa ja näin ollen pysyy suojattuna. Näin ollen suurin osa sensitiivisestä tiedosta voidaan tallentaa luotetun alueen ulkopuolelle. TEE -ympäristössä toimii erilaisia salattuja alustoja, joilla on erilaisia piirteitä ja tarkoituksia toimiessaan luotettuna alueena. Luotettu alue voi toimia virtuaalisena osana käyttöjärjestelmää eli ohjelmistokomponenttina, piiritasolla toteutettuna luotettuna alueena, ulkoisena fyysisenä sirumoduulina, molemmissa rooleissa yhtä aikaa. Yleisimpiä luotettuja alustoja ovat TPM (Trusted Platform Module) ja MTM (Mobile Trusted Module), jotka ovat molemmat määritelty TCG:n (Trusted Computing Group) toimesta. MTM on yksilöity joiltakin osin mobiililaitteilla, mutta muuten MTM- ja TPM-alustat muistuttavat suuresti toisiaan. Muita salattuja alustaja ovat M- Shield, joka perustuu Texas Instrumentin teknologiaan, ohjelmistona toteutettu Java Card, joka perustuu Oraclen teknologiaan ja piiritasolla toteutettu Trust-Zone, joka perustuu ARM:n teknologiaan. Tässä yhteydessä lyhenteellä ARM (sanoista Advanced RISC Machines) tarkoitetaan 32-bittistä mikroprosessoriarkkitehtuu-rilla valmistettua mikroprosessoria eli SoC-mikropiiriä (System-on-a-chip). ARM on RISC-arkkitehtuuri ja nykyisin suosittu etenkin kämmenmikrojen, matkapuhelimien ja sulautettujen järjestelmien suorittimissa. ARM soveltuu pienikokoisiin päätelaitteisiin hyvin, koska sen voi toteuttaa suhteellisen vähäisellä logiikkamäärällä tehokkuuteensa nähden. Pienestä koostaan huolimatta ARM-prosessorit ovat varteenotettavia prosessoreita, koska ne voivat sisältää esimerkiksi muistinhallintayksikön, joka mahdollistaa kehittyneiden käyttöjärjestelmien ajamisen. ARM-prosessorissa luotettu alue on niin sanottu Trust Zone. Tällainen luotettu alue löytyy muun muassa ARMv6KZ-prosessoris-ta. Luotettu alue voidaan toteuttaa kahden virtuaalisen prosessorin avulla, joita tuetaan hardware-pohjaisella pääsyohjauksel-la. Tämä mahdollistaa sovellusten käyttää kahta rinnakkaista aluetta, joista toinen on luotettu ja toinen turvaamaton. Luotetulle alueelle pääsyoikeus on ainoastaan tietyillä sovelluksilla, jotka luotettu alue varmentaa. Turvaamattomalla alueella voidaan käyttää laajempaa käyttöjärjestelmää ja pienempää suojatumpaa järjestelmää luotetulla alueella. Luotettu alue ja turvaamaton alue voivat toimia itsenäisesti toisistaan riippumatta.

Vaihtoehtoisesti järjestelmä voidaan toteuttaa siten, että luotettu alue on SIM-kortti tai luotettu alue on järjestetty päätelaitteeseen asennettavaan ulkoiseen tai sisäiseen sirumo-duuliin. Ohjelmistolla toteutettuna luotettu alue voi olla esimerkiksi Java Card, joka sisältää vahvat sisäiset suojaukset. Tällöin luotettu alue voi olla täysin ohjelmistollisesti toteutettu ilman hardware suojausta.

Olennaista on, että luotettu alue täyttää kontaktittomilta älykorteilta sekä maksujärjestelmiltä vaaditun turvaluokituksen rahalaitosten ja kortin myöntäjien kuten pankkien toimesta, johon turvaluokitukseen yleisesti on käytetty referenssinä EMVCo-spesifikaatiota. Tällöin myös palvelinjärjestelmän omistava toimija hankkii ja säilöö turvallisesti tarvittavat avaimet kyseisen luotetun alueen kanssa toimimiseksi. Tarkemmin sanottuna palvelinjärjestelmä sisältää myös luotetun alueen, joka täyttää maksujärjestelmiltä vaaditun turvaluokituksen. Tällä hetkellä SIM/UICC-ympäristöissä käytössä oleva IMEI-autentikoin-ti ja SIMLock -protokolla eivät kaikilta osin täytä tällaisen järjestelmän vaatimia turvakriteereitä. On havaittu, että pienellä vaivalla käyttäen USB-kaapelia ja PC-tietokonetta voidaan ohittaa kyseinen tunnustautumismenetelmä.

Kuvassa 6 on esitetty kuinka maksusovellus 106 voidaan toteuttaa esimerkiksi Java Card -pohjaisena ratkaisuna turvaelementteineen 65. Tällöin käyttäjän rekisteröityessä kuvan 2 mukaisesti kuvan 6 palvelinjärjestelmään 68, palvelinjärjestelmän 68 luottamus-kortin hallintasovellus 70 paketoi Java Card -sovelluksen JAR/CAP-tiedostoksi sekä generoi siitä APDU-komentosarjat asennusta varten. Tämän jälkeen tuotetut asennustiedostot salataan luotetun alueen vaatimien avainten kanssa ja siirretään https-yhteyden yli käyttäjän päätelaitteeseen isäntä-sovellukseen 63 kuvan 2 vaiheiden 5-9 mukaisesti. Isäntä-sovellus toimii pakettien välittäjänä palvelinjärjestelmän sekä luottamuskortin välillä sekä antaa käyttöliittymän käyttäjälle sallittujen toimintojen ja näkymien avulla. Mikäli päätelaitteen luotetun alueen turva-käytännöt sallivat, Java Card -sovellus kommunikoi suoraan www-palvelimen 69 kanssa ja tällöin isäntä-sovellus 63 toimii ainoastaan käyttöliittymänä käyttäjälle tarjottuihin näkymiin. Toisaalta käyttöliittymä 87 voi olla erillinen ohjelmakomponent-ti kuten kuvassa 6. Isäntä-sovellus 63 on myös allekirjoitettu TEE-alueen vaatimien turvavaatimusten mukaisesti, joten sille saapunut asennuspaketti voidaan asentaa luotetulle alueella JCRE-ympäristöön asennuspaketin sisältämää APDU-komentosarjaa käyttäen. Toisaalta mikäli toimija jostain syystä niin haluaa, asennus voidaan myös suorittaa ulkoisen luotetun toimijan toimesta, joita kutsutaan yleisellä lyhenteellä TSM (Trusted Service Manager). Tällöin luottamuskortin asennuksen kokonaisvastuu ja hallinta siirretään keskitetylle luotetulle kolmannelle osapuolelle. Maksutapahtumien käsittely, autentikointi ja hallinta suoritetaan edelleen toimijan toimesta, kuten maksutapahtuman kuvauksessa kuvissa 3 ja 4 on esitetty.

Kuvan 3 maksutapahtumassa käyttäjä aktivoi toimijan luottamus-kortin käynnistämällä päätelaitteesta käyttäjän maksusovelluk-sen. Käyttäjän maksusovellus suorittaa käynnistyessään automaattisesti APDU primitiivin SELECT, joka aktivoi tämän dokumentin toimijan luottamuskortin sen identiteetin (ID) perusteella. Luottamuskortti on kuitenkin sisäisesti asetettu tilaan, jossa sen todellinen aktivointi ei onnistu ennen palvelinjärjestelmältä saatua toimijan salaisuutta SS2(check), jonka vain toimija tietää. Salaisuus on yksilöllinen jokaiselle asennetulle luotta-muskortille. Palvelinjärjestelmän salaisuuden perusteella muodostetaan PIN(check), jota verrataan rekisteröinnissä luotuun todelliseen PIN-koodiin luottamuskortin tilakoneen aktivoimiseksi. Todellisella aktivoinnilla tarkoitetaan luottamuskortin sisäisen tilakoneen tilaa, jossa kyseessä oleva luottamuskortti voi toimia itsenäisesti suoraan ulkoisen lukijan 67 kanssa. Vasta onnistuneen kirjautumisen jälkeen suoritetaan luottamus-kortin todellinen aktivointi, kun palvelimelta salattuna saatu toimijan salaisuus SS2 on tallennettu luotetun alueen 64 Java Card -sovelluksessa 65 olevaan luottamuskorttiin 100.

Kirjautumisessa käytetään 2-suuntaista tunnistautumista, jossa sekä palvelinjärjestelmä että Java Card autentikoidaan käyttäen niiden yksilöiviä identiteettejä sekä rekisteröintivaiheessa vaihdettuja sertifikaatteja kuvan 2 mukaisesti. Tässä yhteydessä Java Card 65 toimii välineenä maksusovelluksen 106 käyttöoikeuden ohjaamiseksi päälle ja pois. Palvelinjärjestelmän identiteetti on sen www-osoite sertifikaatteineen ja kortin identi teettinä käytetään ennen asennusta paketointivaiheessa sille luotua yksilöllistä identiteettiä. Tämän jälkeen käyttäjä siirtää päätelaitteen ulkoisen lukijan läheisyyteen saatuaan käyttöliittymän kautta tiedon onnistuneesta luottamuskortin aktivoinnista. Ulkoinen lukija 67 kommunikoi ISO/IEC 14443 -standardin mukaan NFC-moduulin 66 kautta APDU-komennoilla Java Card:n 65 kanssa välittäen samalla kauppiaan lukijasta maksutiedot kuten loppusumman käyttöliittymälle 63. Käyttöliittymäsovellus saa maksutiedot älykortista APDU-proto-kollaa käyttäen kuuntelemalla maksusovellukselle 106 saapuneita tapahtumia.

Kun maksusovellus 106 lähettää maksupyynnön palvelinjärjestelmään 68, automaattinen transaktion tarkistusmoduuli 73 tarkistaa kortin tilan (esimerkiksi sertifikaattien päiväykset) sekä maksettavan summan sallittavuuden käyttäjän henkilökohtaisten käyttörajojen suhteen tietokannasta 71 luottamuskortin ID:n perusteella. Henkilökohtainen käyttöraja eli luottolimiitti voidaan tarkistaa sekä päätelaitteella että palvelinjärjestelmässä. Tulos palautetaan symmetrisellä avaimella salattuna päätelaitteeseen älykortille. Tulos sisältää salatun APDU-komennon joka asettaa PIN-koodin Java Card:n APDU:Process primitiivissä. Tämän jälkeen maksu kuitataan eli käyttäjän päätelaite viedään uudestaan ulkoisen lukijan läheisyyteen, joka lukee Java Card -älykortilla olevasta suojatusta muuttujasta tarkistuksen tuloksen ISO/IEC 14443 standardin mukaisesti APDU-komentoja käyttäen.

Kuvassa 7 on esitetty toinen sovellusesimerkki järjestelmässä mahdollisesti käytettävästä arkkitehtuurista. Esimerkkissä käytetään TEE:na TrustZone-alustaa ja kredentiaali -alustana toimii Obc (On board Credential), joka perustuu Nokian teknologiaan, jota käytetään Nokian älypuhelimien alustoissa kuten Windows Phone, Symbian ja Meego. Kyseinen kredentiaali-alusta vastaa hyvin myös EMVCo-spesifikaation mukaisiin vaatimuksiin. "Kredentiaali" sanalla tarkoitetaan kombinaatiota, jossa ohjelma ja salattu tieto tarvitsee salatun varaston ja salatun väylän keskinäiseen kommunikointiin käyttäjän päätelaitteessa. Muita kredentiaali-alustoja ovat TEM, SKS, Flicker ja TruWallet, jotka myös sopisivat mainiosti keksinnön mukaisen maksujärjestelmän alustoiksi ammattimiehelle ilmeisillä muunnoksilla. Kredentiaa-li-alustan tehtävä on hallinnoida luotuja kredentiaaleja luotetulla alueella ja vapauttaa joitakin päätelaitteen alustan salausominaisuuksia sovelluksen käyttöön, joiden näkyvyys riippuu sovelluksen vaatimasta luotettavuustasosta.

Obc kredentiaali-alusta tarvitsee toimiakseen määritellyn luotetun alueen, joka tässä esimerkissä on ARM teknologiaan perustuva TrustZone-alue. Käytännössä tämä tarkoittaa, että TEE -ympäristössä tulee olla määritetty RAM-muistista alue, jota voidaan käyttää, kun salattu merkkijono on vapautettu päätelaitteen käynnistämisprosessissa. Tämä salattu merkkijono on toimitettu ja kovakoodattu päätelaitekohtaiseksi laitevalmistajan toimesta ja sitä ei voi muuttaa tai edes lukea TEE-alueella toimivasta luotetusta alueesta. Obc kredentiaali-alustan yhteydessä luotetulla alueella käytetään LUA-skriptikieltä. LUA-skriptikieli voidaan myös tallentaa Obc tietokantaan, josta se voidaan aina hakea luotetulle alueelle, jokaista operaatiota varten. Järjestelmän mukaisessa Obc-päätelaitteessa 84 on päätelaiteval-mistajan toimesta asennettu Obc-alusta. Tässä sovellusmuodossa päätelaitteelle 84 on tunnusomaista se, että päätelaitteesta 84 löytyy Obc Interpreter tulkkisovellus 77, joka on sen ydin, ja jota käytetään kredentiaalien eristämiseen TEE-alueella 86 toisista mahdollisista kredentiaaleista. Luottamuskortti 100 asennetaan Obc Interpreter tulkkisovelluksen 77 sisään sen eristämiseksi. Edelleen päätelaitteeseen 84 kuuluu Obc Provision Client 74, joka edustaa sovellukselle tarjottavaa rajapintaa ja Obc Credential Manager 75, jonka tehtävä on huolehtia sovellusten yhteyksistä TEE:n 86 kanssa sekä hallita Obc-tietokantaa 78. Tälle maksujärjestelmän sovellusmuodolle on tunnusomaista myös se, että päätelaitteeseen 84 on asennettu sen valmistajan toimesta joukko päätelaitekohtaisia avaimia, jotka ovat nimittäin OPK (Obc Platform Key) avain, sisäinen päätelaitteen avainpari (SK1,PK1) ja ulkoinen päätelaitteen avainpari (SKe,-PKe) . Näitä avaimia käytetään salattuun ja luotettavaan kommunikointiin luotetun alueen ulkopuolisten tahojen kanssa.

Rekisteröintivaiheessa käyttäjän toimesta ladattava maksusovel-lus 106 käsittää Obc Provision Client -ohjelman 74 suojattua kommunikointia varten sekä käyttöliittymäkomponentin 87 käyttäjän kanssa kommunikoimiseksi. Sensitiivisen sovellusosan ja siihen liittyvien salaisuuksien eli kredentiaalien jakelussa ja käytössä tyypillisesti aloitetaan siitä, että Obc Provision Client -sovellus 74 käyttäjän päätelaitteessa 84 luo yhteyden toimijan tai luotetun kolmannen osapuolen palvelinjärjestelmän 85 eli provisiointi-palvelimen 85 hallintasovelluksen 83 kanssa toimien näin palvelinjärjestelmän yhteysvälineinä toimivaan www-palvelimeen 82 päin.

Obc Provision Client -sovellus 74 lähettää laitetoimittajan toimesta sertifioidun yleisen avaimen provisiointi-palvelimelle 85. Provisiointi-palvelin 85 lähettää määrätyn määrän paketteja päätelaitteelle 84. Provisiointi-paketti voi sisältää esimerkiksi ohjelman ja salatun tiedon autentikointiprosessille sekä myös tarvittavan hyväksynnän joka, antaa kyseiselle ohjelmalle oikeuden salattuihin tietoihin. Obc Provision Client -sovellus 74 luo uuden kredentiaalin Credential Managerilla 75 eli lisää ohjelman ja salatun tiedon Obc järjestelmään. Näin Obc Provision Client -sovellus 74 toimii tässä sovellusmuodossa välineinä maksusovelluksen 106 käyttöoikeuden ohjaamiseksi päälle ja pois. Obc Credential Manager 75 salaa lähetetyn provisiointi-palvelimen 85 paketin käyttäen Provision System -sovellusta 76 ja yksityistä osaa päätelaite avaimesta ja suojaa kredentiaaliin kuuluvan salaisuuden käyttäen päätelaitevalmistajan toimesta asennettua päätelaiteelle 84 yksilöityä symmetristä OPK(Obc

Platform Key) avainta. Lopuksi Credential Manager 75 varastoi suojatun salaisuuden ja ohjelman Obc-tietokantaan 78.

Kuvan 7 maksujärjestelmän sovellusmuodossa maksutapahtuma toimii pääpiirteissään kuten kuvissa 3 ja 4 on esitetty. Ero kuvassa 6 esitettyyn sovellusmuotoon tulee vaiheissa 23, 32 ja 53, kun käyttäjä on kirjautunut maksujärjestelmään sisään, päätelaite 84 viedään ulkoisen lukijan 81 viereen. Tällöin ulkoinen lukija 81 aktivoi NFC-moduulin 80 P2P(peer-to-peer)-protokollan yli aktiivisen valitun palvelun nimen tai palvelimen tukiaseman tai R/W (read/write) NFC-protokollalla käyttäen rekisteröitymisessä luotua välittäjäsovellusta eli middlewares 79. Tässä yhteydessä välittäjäsovelluksella 79 tarkoitetaan toimijan sovelluskom-ponenttia, joka vastaanottaa ja välittää NFC-moduulilta 80 saapuvat viestit P2P-protokollan laajennuksen eli LLCP-protokol-lan yli, jonka jälkeen se aktivoi tarvittavan salatun tiedon ja hakee käyttäjätiedot sekä käyttäjän varmennuksen luotetulta alueelta 86 käyttäen Credential Managerein 75 rajapintaa. LLCP-protokollan käyttö ja kutsuminen tapahtuu alustan toimittajan tarjoamien sovellusrajapintojen kautta.

Esimerkkinä ulkoinen lukija 81 lähettää maksupyynnön (150 ; eur; 02/12/2011;Stockmann tapiola) päätelaitteelle 84 NFC : n yli. Välittäjäsovellus 79 vastaanottaa viestit LLCP-protokollan mukaisesti sekä välittää luotetulla alueella 86 toimivalle käyttäjän käyttöliittymän 87 kautta aktivoimalle maksusovelluk-selle 106 saadut tiedot. Maksusovellus 106 tarkistaa onko saldo-muuttujaan talletettu arvo riittävä tapahtuman hyväksynnälle. Jos maksu hyväksytään, siitä lähettää tiedot käyttäjän käyttöliittymälle UI 87 ja eteenpäin palvelinjärjestelmään 85. Luottamuskortin PIN-koodi on syötetty etukäteen järjestelmään kuten vaiheissa kuvien 3 ja 4 vaiheissa 30 ja 47.

Mikäli kommunikoivana osapuolena on kauppiaan ulkoinen lukija tai jokin muu P2P-protokollaa tukeva laite, palautetaan sille takaisin välittäjäsovelluksen kautta PIN-koodin tarkistuksen tulos tai kertakäyttöinen salasana. Vaihtoehtoisesti maksun hyväksyminen voidaan lähettää salattuna ulkoiselle lukijalle toimijan palvelinjärjestelmän kautta Internetiin tai puhelinverkon yli mikäli saatu maksupyyntö sisältää lisäksi kyseisen ulkoisen lukijan tai muun laitteen reitittämiseksi tarvittavan informaation maksun hyväksymistä osoittavan viestin salaamista varten. Informaatio voi olla esimerkiksi IP-osoite tai puhelinnumero sekä ulkoisen lukijan symmetrinen tai julkinen avain.

Kuvan 7 mukaisessa maksujärjestelmän sovellusmuodossa välittä-jäsovellus 79 ja Obc Provision Client -sovellus 74 ovat edullisesti erillisiä ohjelmakoodeja, jotka suorittavat kumpikin omaa tehtäväänsä. Obc Provision Client -sovelluksen 74 tehtävänä on hoitaa päätelaitteen 84 kommunikoinnin palvelinjärjestelmän 85 kanssa ja aktivoida maksusovelluksen 106 käyttöoikeus. Välittä-jäsovellus puolestaan hoitaa päätelaitteen kommunikoinnin maksun saajan NFC-lukijan kanssa. Näin välittäjäsovellus ei näe Obc Provision Client -sovellukselle tulevaa dataa ainakaan selkokielisenä, mikä lisää järjestelmän tietoturvaa.

Seuraavaksi on esitetty eräs esimerkki NFC:n käyttötapauksesta. Käyttäjällä on käytössään esimerkiksi Nokian NFC -teknologiaa tukeva mobiilipäätelaite esimerkiksi Nokia N9 tai Nokia 701, joka sisältää luotetun alueen sisäänrakennettuna ja konfiguroi-tuna päätelaitteistoon. Luotettu alue turvaa sinne asennetun sensitiivisen tiedon ja sovelluksen. Luotetulle alueelle on käyttäjän rekisteröinnin yhteydessä asennettu luottamuskortti. Luottamuskortti sisältää toimijan pankki ja tilitiedot, asiakkaan personoidun korttinumeron sekä salatun avaimen, CA-sertifi-kaatin, luottamuskortin sertifikaatin (sertifikaatti sisältää siis luottamuskortin identiteetin ja julkisen avaimen sekä toimijan palvelinjärjestelmän CA:lla tehdyn allekirjoituksen), jotka ovat kaikki yhteiskooltaan noin 20 - 50 kbytes. Yksittäisten osien koot ovat: CA < 2 kb, salainen avain < 2kb, julkinen avain/sertifikaatti < 2 kb, pankkitiedot < 0,5 kb ja sovellus 15 - 30 kb.

Lisäksi luottamuskortti sisältää sovelluksen Java Cardlet, joka hoitaa APDU-komentojen käsittelyn ulkoisen lukijan kanssa sekä TLS/SSL -yhteyksien luonnin ja hallinnan palvelinjärjestelmän kanssa. Lisäksi Java Cardlet -sovellus hoitaa sertifikaattien ja avaimien käsittelyn päätelaitteen ja palvelinjärjestelmän välillä. NFC-ostoksen tekeminen tapahtuu esimerkiksi seuraavina vaiheina: 1. Asiakas kävelee kauppaan, valitsee ostokset normaalin tapaan ja sitten käynnistää sopivalla hetkellä toimijan sovelluksen. Asiakas antaa sovellukselle käyttäjän salaisuuden SS1, jolloin luottamuskortin varmentaminen suoritetaan luotetulla alueella ja kortti aktivoidaan onnistuneen varmennuksen jälkeen toimijan palvelinjärjestelmän toimesta palvelinjärjestelmän salaisuudella SS2. Lisäksi tarkistuksen tulos tallennetaan luottamuskorttiin. Kommunikointiprotokolla on kaksisuuntainen SSL/TLS GPRS:n, 3G:n tai WLAN:in yli. 2. Asiakas menee kassajonoon ostoksien kanssa. 3. Kassa syöttää ulkoiseen NFC-sirulla varustettuun lukijaan ostosten summan. 4. Käyttäjä vie päätelaitteen ulkoisen lukijan viereen etäisyydelle, joka on pienempi kuin 10 cm, jolloin lukija vie myyntitapahtuman tiedot NFC/APDU -kommunikaatiolla käyttäjän päätelaitteeseen sekä hakee pankkitiedot käyttäjän päätelaitteesta itselleen NFC-standardien mukaisesti. Käyttäjälle näytetään päätelaitteen ruudulla summa ja valinta HYVÄKSY/HYLKÄÄ. 5. Käyttäjän päätelaite lähettää saadut tiedot toimijan palvelinjärjestelmälle (TLS GPRS:n, 3G:n tai WLAN:in yli), joka tallentaa maksutapahtuman tiedot sekä palauttaa tuloksen (oliko summa ok). Tähän voi olla jo tallennettuna pre-paid summa luottamuskortille, jolloin vaihetta 5 ei tarvita. 6. Käyttäjä näyttää päätelaitetta uudelleen kauppiaan ulkoiselle lukijalle, joka lukee hyväksymisen/hylkäyksen. Lisäksi ulkoinen lukija tekee oman päätöksensä offline tarkistuksen perusteella tai kysymällä varmistusta luotottajalta tai toimijalta (tiedot tulevat lukijalle siis vaiheessa 4), palauttaa päätelaitteelle NFC/APDU:a käyttäen pyynnön HYVÄKSYTTY/HYLÄTTY sekä tulostaa kuitin. 7. Käyttäjän päätelaite lähettää vaiheessa 6 saadun tuloksen (commit/rollback) palvelinjärjestelmään. Jos pre-paid maksu on tehty toimijan palvelinjärjestelmään jo aiemmin, vaihetta 7 ei välttämättä tarvita. Tällöin luottamuskortin sisäistä käytössä olevaa käyttövaraa kuvaavaa numeerista muuttujaa päivitetään NFC: n ja APDU:n yli ulkoisen lukijan vaiheessa 6 tekemän päätöksen perusteella. 8. Kauppias lähettää maksutapahtuman tiedot sisältävän paketin pankkiin tai luottoyhtiölle tilitettäväksi.

Seuraavaksi on esitetty maksun saajan eli kauppiaan ulkoisen NFC-lukijan maksutapahtumassa käyttäjän päätelaitteen luottamus-kortille esittämät APDU-komennot, joiden palautteena ulkoinen lukija saa luottamuskortilta luetut arvot sekä suoritettavat toiminnot. Kuvan 3 vaiheessa 24 kauppiaan ulkoinen lukija lähettää käskyn APDU:GET PROCESSING OPTIONS, jossa pyydetään luottamuskortilta seuraavat tiedot, jotka luottamuskortti lähettää ulkoiselle lukijalle:

Application Interchange Profile (mitkä autentikointi muodot tuettuja SDA(static data),DDA(dynamic data authentication) ) . Valitaan esimerksi DDA.

Application File Locator (mitkä tiedostot ja tietueet luetaan luottamuskortilta esimerkiksi offline data autentikoin-tiin kuuluvat tietueet)

Vaiheissa 24 ja 25 NFC-lukija lähettää käskyn APDU:READ RECORD (Read application data), jossa pyydetään luottamuskortilta seuraavat tiedot, jotka luottamuskortti lähettää ulkoiselle lukij alle:

Application Identifier (AID) (luottamuskortin ID) Application Expiration Date (Rekisteröinti vaiheessa määritetty)

Application effective date (Rekisteröinti vaiheessa määritetty)

Application Currency Code (valuutta)

Application Currency Exponent ()

Application Primary Account Number

Application Primary Account Number (PAN) Sequence Number Card Risk management object List 1 (tarkistettavien riskiobjek-tien lista tulee päätteeltä luottamuskortille. Tarkistus tehdään luottamuskortissa. Esim max limit, pin try counter)

Card Risk management object List 2 Cardholder Name Cardholder Name Extended Language Preference CVM List (Card verification Rules: Esim "offline PIN";"online transaction authentication").

Samassa vaiheessa ulkoinen lukija lähettää myös käskyn APDU:GET DATA, jolla se hakee transaktion tiedot.

Verkkoyhteydettömän maksutapahtuman vaiheessa 49 suoritetaan Dynamic Data Authentication (offline data authentication valittu get processing option vaiheessa), jossa käyttäjän päätelaite lähettää ensin luottamuskortin julkisen avai-men/sertifikaatin kauppiaan ulkoiselle lukijalle, joka tarkistaa sertifikaatin allekirjoituksen omasta säilöstään löytyvällä CA sertifikaatilla. Sitten ulkoinen lukija lähettää satunnaista dataa käyttäjän päätelaitteelle, jonka päätelaite allekirjoittaa luottamuskortin yksityisellä avaimella (ICC Private key), ja lähettää allekirjoituksen datasta ulkoiselle lukijalle. Pääte tarkistaa allekirjoituksen julkisella avaimella. Seuraava asiat tarkistetaan: ICC public key certificate (luottamuskortin sertifikaatti) ICC public key reminder ICC public key exponent CA public key index Issuer public key certificate Issuer public key reminder Issuer public key exponent

Kuvan 3 vaiheessa 32 ulkoinen lukija suorittaa Cardholder verification (offline PIN prosessing) toiminnon lähettämällä käskyn APDU:VERIFY, jossa pyydetään käyttäjän päätelaitteen luottamuskortilta PIN-koodin tarkistuksen tuloksen "onnistui" tai "ei onnistunut". PIN-koodin tarkistuksen tulos saadaan vertaamalla rekisteröinnissä muodostettua PIN-koodia maksutapahtuman aikana muodostettuun PIN(check)-koodiin .

Kuvan 3 vaiheessa 34 ulkoinen lukija suorittaa käskyn APDU:GET DATA, jolla se hakee päätelaitteelta maksutapahtumien laskurin lukeman. Edelleen vaiheessa 34 ulkoinen lukija suorittaa käskyn APDU: GENERATE AC (Transaction data to card -amount, date, time jne), jossa ulkoinen lukija ja päätelaite sopivat käytetäänkö tarkistukseen online- vai offline-tarkistusta, ARQC (online) tai Transaction Certificate (offline - accepted) tai AAC (offline -declined). Jos luottamuskortti palauttaa ulkoiselle lukijalle Transaction certificate kryptogrammin, kryptogrammi tarkistetaan ja positiivisesti offline-transaktio hyväksytään (AAC kryptogrammi hylätty offline-transaktio). Jos luottamuskortti palauttaa ulkoiselle lukijalle toimijan palvelinjärjestelmän avaimella (tallennettu luotetulle alueelle) muodostetun ARQC kryptogrammin, lähetetään se edelleen ulkoisen lukijan kautta kortin myöntäjälle tarkistettavaksi. Jos toimija on luottamuskortin alkuperäinen myöntäjä tai muutoin pitää hallussaan ARQC kryptogrammin tarkistukseen tarvittavaa salausavainta, ARQC lähetetään toimijan palvelinjärjestelmään, joka tarkistaa ja todentaa omalla vastaavalla avaimellaan viestin. Palvelinjärjestelmä palautta ARPC - Authorization Response kryptogrammin takaisin ulkoiselle lukijalle ja edelleen luottamuskortille. Näistä tehdään transaktion hyväksymispäätös.

Taulukko la.

Taulukko lb.

Taulukko 2a.

Taulukko 2b.

Claims (19)

1. Maksujärjestelmä sähköisen j a varmistetun maksutiedon tuottamiseksi maksun saaj alle, j ohon maksuj ärj estelmään kuuluu - käyttäj än päätelaite (62,84) käsittäen edelleen - maksusovelluksen (10 6) maksupyyntöj en muodostamiseksi, - luotetun alueen ( 64, 8 6) ohj elmallisen salauselementin (100) tallentamista ja käyttöä varten, RFID-yhteysvälineet (66, 8 0) maksutiedon toimittamiseksi maksun saaj an päätelaitteeseen (67, 81), yhteysvälineet palvelinjärjestelmään ( 63, 7 4) suoj at- tua yhteysprotokollaa käyttäen, j a sanottuun salauselementtiin (100) liittyvät välineet (65,74) maksusovelluksen (106) käyttöoikeuden ohjaamiseksi päälle ja pois, - toimij an palvelinjärj estelmä (68,85) käsittäen edelleen hallintasovelluksen (70, 83) päätelaitteen tunnistamiseksi j a hallinnoimiseksi, - tietokannan (71) käyttäj äkohtaisia tietoj a j a avaimia varten mukaan lukien kunkin maksusovelluksen (106) salaisuuden (SS2), yhteysvälineet (69,82) päätelaitteeseen (62,84) suoj attua yhteysprotokollaa käyttäen, missä maksusovelluksen (106) käyttö on sovitettu kaksivaiheiseksi käsittäen käyttäj än rekisteröitymisen palvelinjärj estelmään (68,85) ja maksusovelluksen (10 6) validiteetin ohj auksen sanotun käyttöoikeuden avulla käyttäen salauselementtiä (10 0) j a ainakin määrävälein palvelinj ärj estelmältä (68,85) saatua automaattisesti muodostettua maksusovelluksen (106) salaisuutta (SS2), tunnettu siitä, että maksupyynnön validiteetti on sovitettu ohj attavan maksusovelluksen (10 6) PIN-koodin avulla, joka PIN- koodi käsittää yhteisesti mainitun palvelinjärjestelmältä saadun maksusovelluksen (106) salaisuuden (SS2) j a rekisteröintivaiheessa käyttäj än antamista tiedoista luodun käyttäj än salaisuuden (SS1) .

2. Patenttivaatimuksen 1 mukainen maksuj ärj estelmä, tunnettu siitä, että päätelaitteessa (62,84) on salauselementin (100) valvoma luottolimiittilaskuri.

3. Patenttivaatimuksen 2 mukainen maksuj ärj estelmä, tunnettu siitä, että päätelaitteen ( 62,84) RFID-yhteysvälineet (66, 80) käsittävät NFC-moduulin (80).

4. Jonkin patenttivaatimuksen 1-3 mukainen maksuj ärj estelmä, tunnettu siitä, että päätelaitteessa (62) on maksusovellus sanotulla luotetulla alueella (65) ja sen auktorisoima isäntä-sovellus (63) turvaamattomalla alueella käyttöliittymän j a palvelinyhteyden muodostamiseksi.

5. Jonkin patenttivaatimuksen 1-4 mukainen maksuj ärj estelmä, tunnettu siitä, että maksupyynnön validiteetin ohj aus on sovitettu tapahtuvan 2 - 48 h välein.

6. Jonkin patenttivaatimuksen 1-4 mukainen maksuj ärj estelmä, tunnettu siitä, että maksupyynnön validiteetin ohj aus on sovitettu suoritettavan joka maksutapahtuman yhteydessä.

7. Jonkin patenttivaatimuksen 1-6 mukainen maksuj ärj estelmä, tunnettu siitä, että palvelinjärj estelmältä (68,85) saatu maksusovelluksen (10 6) salaisuus (SS2) on muodostettu satunnaisesti, kuten niin, että maksusovelluksen salaisuus on sovitettu käytettäväksi yhdessä maksutapahtumassa.

8. Jonkin patenttivaatimuksen 1-7 mukainen maksujärjestelmä, tunnettu siitä, että käyttäjän päätelaitteen (84) RFID-yhteysvälineet palvelinjärjestelmään (85) ovat erillään sanotuista välineistä (74) maksupyynnön validiteetin ohj aamiseksi.

9. Menetelmä maksun suorittamiseksi, jossa menetelmässä: vastaanotetaan maksutietoa maksupäätteeltä käyttäj än päätelaitteeseen, - vastaanotetaan automaattisesti muodostettu maksusovelluksen salaisuus toimij an palvelinj ärj estelmästä päätelaitteeseen, aktivoidaan mainitussa käyttäj än päätelaitteessa luottamuskortti hyödyntämällä mainittua maksusovelluksen salaisuutta, j a lähetetään mainitusta käyttäj än päätelaitteesta mainitulle maksupäätteelle luottamuskortin tietoa maksutapahtuman suorittamiseksi, missä menetelmässä - muodostetaan koodi käyttäj än antamista tiedoista luodusta käyttäj än salaisuudesta j a palvelinjärj estelmästä saadusta mainitusta maksusovelluksen salaisuudesta, j a - aktivoidaan mainitulla koodilla käyttäj än päätelaitteessa mainittu luottamuskortti maksutapahtuman suorittamista varten.

10. Vaatimuksen 9 mukainen menetelmä, jossa: lähetetään palvelinj ärj estelmälle kirj autumistietoj a j ärj estelmään kirj autumiseksi, j a vasteena onnistuneelle kirj autumiselle, vastaanotetaan mainittu maksusovelluksen salaisuus.

11. Vaatimuksen 9 tai 10 mukainen menetelmä, jossa: vastaanotetaan tai määritetään luottamuskorttiin liittyvä luottolimiittilaskurin arvo päätelaitteessa, vasteena hyväksytylle maksutapahtumalle, pienennetään luottolimiittilaskurin arvoa päätelaitteessa, j a käytetään luottolimiittilaskurin arvoa maksupyynnön validiteetin ohj auksessa niin, että maksutapahtuma estetään, jos luottolimiittilaskuri osoittaa, että luotto on riittämätön.

12. Menetelmä maksun suorittamiseksi, jossa menetelmässä: - luodaan luottamuskortti palvelinjärj estelmässä, j a - lähetetään mainitun luottamuskortin tietoj a päätelaitteeseen käytettäväksi maksutapahtuman suorittamisessa, - muodostetaan maksusovelluksen salaisuus palvelinjärjestelmässä, j a - saatetaan mainittu maksusovelluksen salaisuus päätelaitteen käyttöön maksutapahtuman suorittamista varten, missä menetelmässä - muodostetaan palvelinjärj estelmään automaattisesti mainittu maksusovelluksen salaisuus ja käyttäjän antamista tiedoista käyttäj än salaisuus, - muodostetaan koodi mainitusta käyttäj än salaisuudesta j a mainitusta maksusovelluksen salaisuudesta, j a - j ärj estetään käyttäj än päätelaitteeseen toimitettava luottamuskortti aktivoitavaksi mainitulla koodilla maksutapahtuman suorittamista varten.

13. Vaatimuksen 12 mukainen menetelmä, jossa: - vastaanotetaan päätelaitteelta kirj autumistietoj a j ärj estelmään kirj autumiseksi, j a - vasteena onnistuneelle kirj autumiselle, saatetaan mainittu maksusovelluksen salaisuus päätelaitteen käyttöön.

14. Jonkin vaatimuksen 9-13 mukainen menetelmä, jossa mainittu maksusovelluksen salaisuus on muodostettu satunnaisesti siten, että mainittu maksusovelluksen salaisuus on j ärj estetty käytettäväksi yhdessä maksutapahtumassa.

15. Laite, joka käsittää ainakin yhden prosessorin, muistia ja tietokoneohjelmakoodia mainitussa muistissa, joka tietokoneohjelmakoodi on järjestetty saamaan laitteen, kun sitä suoritetaan mainitulla ainakin yhdellä prosessorilla, suorittamaan jonkin patenttivaatimuksen 9-11 mukaisen menetelmän.

16. Palvelinjärj estelmä, joka käsittää ainakin yhden prosessorin, muistia j a tietokoneohj elmakoodia mainitussa muistissa, joka tietokoneohj elmakoodi on j ärj estetty saamaan j ärj estelmän, kun sitä suoritetaan mainitulla ainakin yhdellä prosessorilla, suorittamaan jonkin patenttivaatimuksen 12 - 14 mukaisen menetelmän.

17. Laite maksun suorittamista varten, joka laite käsittää: - tietoliikennevälineet maksupäätteen kanssa kommunikoimista varten, - tietoliikennevälineet palvelinjärj estelmän kanssa kommunikoimista varten, - välineet maksutiedon vastaanottamiseksi maksupäätteeltä, - välineet automaattisesti muodostetun maksusovelluksen salaisuuden vastaanottamiseksi toimij an palvelinjärj estelmästä päätelaitteeseen, - välineet luottamuskortin aktivoimiseksi mainitussa käyttäj än päätelaitteessa hyödyntämällä mainittua maksusovelluksen salaisuutta, - välineet luottamuskortin tiedon lähettämiseksi mainitusta käyttäj än päätelaitteesta mainitulle maksupäätteelle maksutapahtuman suorittamiseksi, - välineet koodin muodostamiseksi käyttäj ältä saadusta käyttäj än salaisuudesta j a palvelinjärj estelmästä saadusta mainitusta maksusovelluksen salaisuudesta, j a - välineet mainitun luottamuskortin aktivoimiseksi mainitulla koodilla käyttäjän päätelaitteessa maksutapahtuman suorittamista varten.

18. Järjestelmä maksun suorittamista varten, joka järjestelmä käsittää: - välineet luottamuskortin luomiseksi, j a - välineet mainitun luottamuskortin tietoj en lähettämiseksi päätelaitteeseen käytettäväksi maksutapahtuman suorittamisessa, tunnettu siitä, että j ärj estelmä käsittää - välineet maksusovelluksen salaisuuden automaattiseksi muodostamiseksi palvelinjärj estelmässä, j a - välineet mainitun maksusovelluksen salaisuuden saattamiseksi päätelaitteen käyttöön mainitun luottamuskortin aktivoimiseksi maksutapahtuman suorittamista varten - välineet mainitun maksusovelluksen salaisuuden j a käyttäj än salaisuuden muodostamiseksi, - välineet koodin muodostamiseksi mainitusta käyttäj ältä saadusta käyttäj än salaisuudesta j a mainitusta maksusovelluksen salaisuudesta, j a - välineet käyttäj än päätelaitteeseen toimitettavan luottamuskortin järjestämiseksi aktivoitavaksi mainitulla koodilla maksutapahtuman suorittamista varten.

19. Vaatimuksen 18 mukainen j ärj estelmä, joka käsittää : - välineet tiedon vastaanottamiseksi käyttäj ältä käyttäj än salaisuuden muodostamiseksi, j a - välineet mainitun käyttäj än salaisuuden muodostamiseksi mainitun tiedon perusteella.