You are here: TUTWiki>Tietoturva/Tutkielmat>NiemelaA?>2007-22

Risto Mäntylä:

Mobiilivarmenne

Johdanto

Harjoitustyössä esitellään matkapuhelimilla tai muulla mobiilipäätelaittella tehtävää julkisen avaimen menetelmään perustuvaa digitaalista allekirjoitusta. Mobiili PKI:ta (Public Key Infrastructure) käytetään erilaisiin sähköisiin varmennepalveluihin, kuten sähköinen allekirjoitus ja sähköinen henkilön tunnistaminen ja käyttäjän vahva todentaminen. Lähtökohtana työssä käytetään FiCom Ry:n soveltamisohjetta ETSI:n MSS-standardeille (Mobile Signature Service). Harjoitustyössä esitellään MSS-standardin arkkitehtuuria, tietoturvauhkia sekä käydään läpi vaihe vaiheelta koko allekirjoitustapahtuman kulku. Lisäksi työssä on paneuduttu lyhyesti MSS-standardin palveluntarjoajan rajapintaan.

"Varmenne on luotettavan kolmannen osapuolen digitaalisesti allekirjoittama todistus siitä, että tietty julkinen avain kuuluu tietylle avaimen käyttäjälle." [4] Mobiilivarmenteella tarkoitetaan matkapuhelimilla tai muulla mobiilipäätelaittella olevaa tunnistetta käyttäjästä (kansalaisvarmenne SIM-kortilla), jonka perusteella voidaan suorittaa julkisen avaimen menetelmään perustuvaa digitaalista allekirjoitusta. Mobiili PKI:ta (Public Key Infrastructure) käytetään erilaisiin sähköisiin varmennepalveluihin, kuten sähköinen allekirjoitus ja sähköinen henkilön tunnistaminen ja käyttäjän vahva todentaminen

Tarve yhtenäisen mobiili-PKI:n luomiseksi syntyi, kun Suomen markkinoiden pienuuden vuoksi ei operaattoreilla tai pankeilla ollut mahdollisuutta toteuttaa varmentamista tukien jokaista olemassa olevaa tekniikkaa. Yhtenäisellä mobiili-PKI:lla tuodaan yksinkertainen rajapinta käyttäjälle, sekä palveluntarjoajalle, jonka avulla voidaan liittää sähköinen allekirjoitus sähköiseen viestintään ja asiointiin. Sen myötä matkapuhelimesta saadaan ajasta ja paikasta riippumatta tunnistautumis- ja allekirjoitusväline sähköiseen kaupankäyntiin. Matkapuhelimen SIM-korttiin voidaan asentaa kansalaisvarmenne (SATU) [5], joka on valtion takaama sähköinen henkilöllisyys ja joita hallinnoi Väestörekisterikeskus. Mobiilivarmenteessa SIM-kortille on asennettuna yksityiset PKI-avaimet, joita suojataan tunnusluvulla. Tunnistuspalvelua käytettäessä varmennepalvelu käy hakemassa Väestörekisterikeskuksesta henkilön varmenteet ja mahdolliset sulkulistat, joita tunnistustapahtuma tarvitsee.

Lyhenteet ja määritelmät

  • ETSI: European Telecommunications Standards Institute on riippumaton sekä voittoa tavoittelematon eurooppalainen telealan standardointijärjestö.
  • MSS-standardi: Mobile Signature Service, ETSI TS 102 204:ssä määritelty standardi palveluntarjoajan rajapinnalle mobiilissa allekirjoituspalvelussa [2]. Mobile signature Roaming Service on määritelty standardissa ETSI TS 102 207, ja se liittyy oleellisesti MSS-standardiin [3].
  • MSSP: Mobile Signature Service Provider. Toimija, joka tarjoaa HMSSP-palveluja käyttäjille ja mahdollistaa AE- ja RE-palvelut palveluntarjoajalle. HMSSP:llä tarkoitetetaan Home MSSP:tä, eli käyttäjän kotioperaattoria [1].
  • Käyttäjä: Mobiililaitteen haltija. Palveluntarjoajan ja kotioperaattorin (HMSSP:n) asiakas.
  • AP: Palveluntarjoaja on toimija, joka tarvitsee käyttäjältä mobiiliallekirjoituksen. AP:t ovat AE:n asiakkaita [1].
  • AE: Acquiring Entity on toimija, joka tarjoaa palveluntarjoajille standardin mukaisen rajapinnan mobiiliallekirjoituspalveluun. AE:t kommunikoivat palveluntarjoajien ja käyttäjän kotioperaattorin välillä [1].
  • RE: Routing Entity on toimija, joka reitittää liikennettä AE:n ja HMSSP:n välillä. RE voi olla AE:n tai HMSSP:n järjestelmän komponentti tai kolmannen osapuolen tarjoama järjestelmä [1].

ETSI:n MSS-standardi

ETSI:n MSS-standardit määrittelevät mobiililaitteilla käytettävän sähköisen allekirjoituspalvelun, jonka avulla palveluntarjoaja voi pyytää sen käyttäjää allekirjoittamaan jotakin sisältöä matkapuhelimella. Tällainen sisältö liittyy yleensä käyttäjän vahvaan tunnistamiseen tai todentamiseen liittyvään tunnistushaasteeseen. Sähköisen kaupankäynnin vahvistus tai verkkopankin käyttäminen mobiililaitteella ovat hyviä esimerkkejä, jossa mobiilia allekirjoitusta käytetään. ETSI:n MSS-arkkitehtuuri on käytännössä määritelty kahdessa eri standardissa, jotka ovat ETSI TS 102 204 ja ETSI TS 102 207. Näistä ensimmäinen määrittelee allekirjoituspyynnöt mahdollistavan rajapinnan. ETSI:n arkkitehtuurissa AP:lla ei tarvitse olla suoraa rajapintaa käyttäjän kotioperaattoriin, vaan riittää että palvelutarjoajalla on minkä tahansa toimijan tarjoama ETSI TS 102 204:n mukainen rajapinta. Jälkimmäinen standardi määrittelee allekirjoituspyyntöjen reitittämisen eri MSSP:eiden välillä, eli niin sanotun allekirjoitusvierailun (mobile signature roaming). Vastaavanlaista tekniikkaa käytetään mm. GSM-verkossa operaattorien välisessä verkkovierailussa, joka mahdolistaa eri operaattoreiden välillä tapahtuvat puhe- ja SMS-palvelut.

FiCom:in suositus MSS-standardille

Teknisesti FiCom-suositus noudattaa ETSI:n standardeja, mutta allekirjoitusvierailu on määritelty tiukemmin. Palveluntarjoajan on tehtävä erilliset sopimukset kaikkien niiden MSSP:iden kanssa, joiden käyttäjille se haluaa lähettää allekirjoituspyyntöjä. Lisäksi palveluntarjoajalla on oltava sopimus AE:n kanssa. Lisäksi AE:lla täytyy olla sopimus vähintään yhden MSSP:n kanssa. FiCom:in suositus mahdollistaa siis, sen että AP tavoittaa yhden teknisen rajapinnan kautta kaikki ne käyttäjät, joiden MSSP:iden kanssa palveluntarjoajalla on sopimus.

arkkitehtuuri.jpg
Kuva1: Esimerkki FiCom-suosituksen mukaisesta ETSI:n MSS-arkkitehtuurista [1]

Kuvassa 1 on esitelty FiCom-suosituksen mukainen konfiguraatio MSS-arkkitehtuurista. Kuten kuvasta huomataan, AE voi olla osa MSSP-järjestelmää (AE MSSP1:ssä), mutta se voi olla myös kolmannen osapuolen tarjoama palvelu (AE1 ja AE2). Jälkimmäisessä tapauksessa AE:lla tulee olla sopimussuhde ja ETSI TS 102 207-rajapinta vähintään yhteen MSSP:iin, jonka avulla AE tavoittaa myös muiden operaattorien käyttäjät. Jos MSSP ulkoistaa AE:n, tarkoittaa se yleensä sitä, että AE:n rooli korvataan RE:llä (Routing Entity), jonka avulla viestejä voidaan reitittää operaattoreiden välillä. Mikäli käyttäjällä on usean HMSSP:n kanssa mobiilin allekirjoituksen mahdollistama sopimus, niin tällöin käyttäjän eri liittymille luodaan erilliset varmenteet. Käyttäjällä voi olla myös useampi varmenne yhtä liittymää kohden.

Ficom- ja ETSI-arkkitehtuurin eroavaisuudet

Kuten aiemmin mainittiin, AP:lta edellytetään erilliset sopimukset AE-entiteetin kanssa ja kaikkien HMSSP:iden kanssa, joiden käyttäjille AP haluaa lähettää allekirjoituspyyntöjä. Palveluntarjoajalla voi olla sopimus useammankin kuin yhden AE:n kanssa, mutta sitä ei suositella, koska FiCom-suosituksen päätavoite on taata palveluntarjoajan käyttäjien saavutettavuus, yhden teknisen rajapinnan avulla.

ETSI:n määrittelemiä kahta asynkronista viestintapaa ei ole huomioitu. FiCom ei huomioi näitä.

ETSI:n standardit mahdollistavat palveluviestien XML-allekirjoitukset. FiCom ei huomioi näitä.

FiCom-suositus ei ota kantaa erillisiin (MSSP:eiden ulkopuolisia) validoiviin (VE, Verifying Entity) tai käyttäjän identiteetin kertoviin toimijoihin.

Tietoturvauhat

Asiattomat allekirjoituspyynnöt

MSS-arkkitehtuurissa on tunnistettavissa kaksi tietoturvauhkaa perinteisten uhkien lisäksi. Ensimmäinen on matkapuhelimen häirintä asiattomilla allekirjoituspyynnöillä. Jos allekirjoituspyynnön yhteystietona käytetään ainoastaan käyttäjän matkapuhelinnumeroa, on mahdollista harhauttaa palveluntarjoajaa lähettämään allekirjoituspyyntöjä muiden käyttäjien matkapuhelimiin. Jos hyökkäyksen kohteena oleva käyttäjä allekirjoittaa saamansa pyynnön, hyökkääjä saa haltuunsa käyttäjän identiteetin. Täten hyökkääjä pystyy ensiintymään palveluntarjoajalle toisena käyttäjänä. Vaikka käyttäjä ei allekirjoittaisikaan väärennettyjä pyyntöjä on vaarana käyttäjien luottamuksen menettäminen mobiilia allekirjoitusta kohtaan.

FiCom:in parannus ETSI:n standardiin on häirinnön estokoodi. Palveluntarjoajan asiointikanavassa käyttäjän yhteystietona kysytään puhelinnumeron lisäksi häirinnän estokoodi. Häirinnän estokoodin validiuden tarkistaa käyttäjän HMSSP, jonne on koodi on tallennettu. Mikäli koodit eivät täsmää HMSSP hylkää allekirjoituspyynnön.

Allekirjoituspyynnön liittäminen väärään istuntoon

Toinen tietoturvauhka MSS-arkkitehtuurissa on allekirjoituspyynnön liittäminen väärään istuntoon. Jos käyttäjä käynnistää useamman allekirjoitustapahtuman lähes samanaikaisesti on vaarana, että käyttäjä ei tiedä mihin kontekstiin kukin allekirjoituspyyntö liittyy.

FiCom-suositukseen on lisätty allekirjoitustapahtuman kontekstin osoittamiseksi istuntotunniste, jonka palveluntarjoaja generoi jokaiselle erilliselle tapahtumalle. On olennaista myös, että HMSSP:t näyttävät istuntotunnuksen päätelaitteelle (käyttäjälle) allekirjoituspyynnön yhteydessä ja opastavat käyttäjää istuntotunnuksen käytössä. Istuntotunnuksena tulisi käyttää vähintään neljä merkkiä pitkää arvoa ja sen tulee olla yksiselitteinen palveluntarjoajan järjestelmässä.

Ratkaisemattomat ongelmat

Vaikka häirinnän estokoodi estää hyökkääjiä lähettämästä allekirjoituspyyntöjä palveluntarjoajan asiointikanavaan, voidaan käyttäjää silti häiritä WAP-asiointikanavassa. WML-lomakkeiden avulla hyökkääjä voi yrittää matkia oikean WAP-asiointikanavan ja allekirjoitustapahtuman ulkoasua mobiililaitteella. Tällä pyritään käyttäjien SPIN-koodien urkintaan. Todellista hyötyä urkinnasta ei välttämättä ole, mutta sillä pystytään aiheuttamaan epäluottamusta mobiilivarmennetta kohtaan.

Toinen ongelma liittyy binääridatan tiivisiteiden allekirjoittamiseen. Jotkin teksti- ja kuvatiedostoformaatit sallivat sisällön muuttamisen tiivisteen muuttumatta. Tämä on mahdollista, esimerkiksi siten, että muutetaan ensin varsinaista sisältöä ja sen jälkeen lisätään metatietoa sekaan sopivasti, jolloin tiiviste saadaan pysymään samana. Tämä on vähintäänkin teoreettinen uhka ja on erittäin työläs toteuttaa käytännössä.

Allekirjoitustapahtuman tekninen kuvaus

  1. Käyttäjä on käynnistänyt istunnon palveluntarjoajan kanssa ja istunnon aikana tulee tarve käyttää mobiilivarmennetta, jotta käyttäjä voidaan tunnistaa vahvasti. Palveluntarjoajalla (AP) ja AE:lla on sopimus ja ETSI TS 102 204-standardin mukainen rajapinta, jonka avulla allekirjoituspyyntö voidaan lähettää. Asiointikanavaa pitkin AP selvittää käyttäjän puhelinumeron, muodostaa allekirjoitettavan sisällön ja lähettää tämän AE:lle.
  2. AE käyttää puhelinumeroa selvittääkseen käyttäjän HMSSP:n ja lähettää viestin edelleen sille käyttäen ETSI TS 102 207-standardin mukaisen rajapinnan kautta.
  3. HMSSP varmistaa, että sillä ja viestin lähettäneellä palveluntarjoajalla on voimassa oleva palvelusopimus. Mikäli näin on, HMSSP toimittaa viestin edelleen käyttäjän päätelaitteelle.
  4. FiCom suosittelee, että päätelaitteella näytetään aina ulkoasultaan samanlaiset viestit, riippumatta siitä, mistä operaattorista tai palveluntarjoajasta on kyse. Ensimmäisessä näytössä näytetään istuntotunniste risuaidoilla erotettuna sekä palvelutarjoajan nimi (kuva 2).
  5. Seuraavassa näytössä käyttäjää pyydetään tunnistautumaan kirjoittamalla SPIN-koodi allekirjoituksen vahvistamiseksi.
  6. Kolmas näyttö käyttäjän päälaitteella on vapaaehtoinen ja se sisältää mahdollisen kuittausviestin tapahtuman onnistumisesta tai epäonnistumisesta.
  7. HMSSP lähettää sähköisen allekirjoituksen AE:n kautta palveluntarjoajalle.
  8. Halutessaan AP voi validoida tapahtuman, jonka jälkeen AP lähettää kuittausviestin samaa reittiä pitkin HMSSP:lle. Kuittausviesti voi sisältää myös päätelaitteelle toimitettavan kuittauksen. HMSSP vastaa AE:n kautta palveluntarjoajalle kuittausviestin vastaanottamisesta.

naytot.jpg
Kuva 2: Päätelaitteella näytettävät näytöt allekirjoituksen eri vaiheissa.[1]

Jos allekirjoitustapahtuma epäonnistuu missä tahansa kohdassa, AP:lle ilmoitetaan siitä virheilmoitusviestillä. AP lähettää käyttäjän HMSSP:lle viestin tapahtuman epäonnistumisesta. Viesti voi sisältää myös käyttäjän päätelaitteelle lähettävän virheilmoituksen.

Palveluntarjoajan rajapinta

FiCom-arkkitehtuurin mukaisessa allekirjoitustapahtumassa käytetään neljää erilaista palveluviestiä, jotka ovat allekirjoituspyyntö (MSS_SignatureReq), allekirjoitusvastaus (MSS_SignatureResp) sekä vapaaehtoinen kuittauspyyntö (MSS_ReceiptReq) ja kuittausvastaus (MSS_ReceiptResp). ETSI:n MSS-standardi määrittelee myös seuraavat viestityypit: MSS_StatusReq, MSS_StatusResp, MSS_RegistrationReq, MSS_RegistrationResp, MSS_ProfileReq, MSS_ProfileResp, MSS_HandshakeReq ja MSS_HandshakeResp. Näitä ei kuitekaan ole huomioitu FiCom:in suosituksessa.

Koko allekirjoitustapahtuma suoritetaan AP:n AE:hen muodostaman HTTP-yhteyden aikana. AP lähettää palvelupyynnön HTTP Pyyntönä ja AE vastaa siihen HTTP vastauksen avulla. Itse palveluviestit kulkevat HTTP-viestin sisällä SOAP-kirjekuorissa. SOAP (Simple Object Access Protocol) on tietoliikenneprotokolla, jonka avulla voidaan etäkutsua palvelujen proseduureja. SOAP perustuu XML-kieleen (Extensible Markup Language) ja sit käytetään yleensä HTTP(S)-protokollan avulla.

SOAP-kirjekuoret koostuvat otsikko- (env:Header) ja sisältöelementistä (env:Body). FiCom-suosituksen palveluviesteissä otsikkoelementtiä ei tarvitse käyttää. Sisältöelementti on pakollinen ja sen sisältää, jonkin edelle mainituista palveluviestin tyypeistä. Alla on kuvattuna esimerkki HTTP-viestin sisälle kääritystä palveluviestistä.

POST /MSS_Signature HTTP/1.1
Host: mss.laukaisualusta.com
ContentType: application/soap+xml; charset="utf8"
ContentLength: nnnn
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soapenvelope">
    <env:Body>
        <MSS_Signature>
        <!- MSSpalveluviesti -->
        <MSS_ReceiptReq xmlns="http://uri.etsi.org/TS102204/v1.1.2#"         xmlns:fi="http://mss.ficom.fi/TS102204/v1.0.0#"...>  
        </MSS_Signature>
    </env:Body>
</env:Envelope>
Kaikki allekirjoitustapahtuman aikana tapahtuvat virhetilanteet välitetään myös SOAP:n avulla. SOAP 1.2:n määrittelevä standardi sisältää myös virhetiedotusmekanismin (SOAP FAULT), jota myös MSS-standardi käyttää.

Lähteet

[1] FiCom Ry, Soveltamisohje ETSI:n MSS-standardeille V1.1, http://www.ficom.fi/ohjeita/ohjeita_2.html [Viitattu 17.09.2009]
[2] The European Telecommunications Standards Institute, Mobile Signature Service, ETSI TS 102 204 V1.1.4 (2003-08)
[3] The European Telecommunications Standards Institute, Specifications for Roaming in Mobile Signature Services, ETSI TS 102 207 V1.1.3 (2003-08)
[4] Viestintävirasto, Varmenne, http://www.ficora.fi/index/palvelut/palvelutaiheittain/tietoturva/pki/varmenne.html, luettu 29.10.2009
[5] Väestörekisterikeskus, Sähköinen henkilöllisyys, http://www.vaestorekisterikeskus.fi/vrk/home.nsf/www/sahkoinenhenkilollisyys, luettu 29,10,2009

-- AnttiNiemela? - 16 Sep 2009
Topic attachments
I Attachment Action Size Date Who Comment
arkkitehtuuri.jpgjpg arkkitehtuuri.jpg manage 57.9 K 17 Sep 2009 - 01:00 UnknownUser  
naytot.jpgjpg naytot.jpg manage 151.4 K 05 Oct 2009 - 10:48 UnknownUser  
Print version |  PDF  | History: r6 < r5 < r4 < r3 | 
Topic revision: r6 - 20 Nov 2009 - 16:19:19 - AnttiNiemela?
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback