Uute eID rakenduste loomine toorik

Allikas: eid.eesti.ee

eID funktsioonide tehnoloogia nüansid

Ülevaade põhifunktsioonide kaupa

Kõigepealt räägime tehnoloogilisest taustast ja nüanssidest eID põhifunktsioonide kaupa, millega võib olla uute eID rakenduste loomisel vaja kokku puutuda.


Isikutuvastamine

EID kaartidel on sertifikaat digitaalseks isikutuvastuseks. Kui kasutaja suudab tõestada, et tal on ligipääs selle sertifikaadi salajasele võtmele, siis usume, et tegu on sertifikaadi omanikuga.

Isiku tuvastamine toimub vastavalt allolevale (lihtsustatud) protokollile:

  1. Kasutaja esitab süsteemile mingi sertifikaadi ning väidab, et ta on selle omanik.
  2. Süsteem genereerib juhusliku, ühekordse arvu ehk nonsi (nonce), mis antakse kasutajale isikutuvastusvõtmega allkirjastamiseks.
  3. Kasutaja lukustab lahti kaardil oleva isikutuvastuseks mõeldud salajase võtme, kasutades selleks PIN1-koodi.
  4. Kaardile antakse nonss, mille see allkirjastab, ning kaardilt loetakse tulemus, mis edastatakse süsteemile.
  5. Süsteem kontrollib, kas antud allkiri verifitseerub sertifikaadil oleva avaliku võtmega.
  6. Süsteem kontrollib sertifikaadi kehtivust (vt Sertifikaatide kehtivuse kontroll).

Kui kõik õnnestus, siis võib eeldada, et kasutaja on tõesti sertifikaadi omanik -- ja kuna sertifikaadil on isiku nimi ning isikukood, siis on ka teada omaniku identiteet. Kuigi tegelikult võib olla kasutaja lihtsalt keegi, kellel on sertifikaadi omaniku kaart ning teab selle PIN1, ei saa seda enam kuidagi kontrollida.

Isikutuvastamise näitekoodi näeb eraldiseisva rakendusena ning ka avalduste kasutusmalli koosseisus.

Veebis

Veebis toimub isiku tuvastamine SSL/TLS käepigistuse (handshake) käigus, kus kontrollitakse ka kliendi sertifikaati. Protokolli põhjalik kirjeldus on kättesaadav Wikipediast, ent lühidalt kokkuvõetuna tehakse sama, mis eelnevalt kirjeldatud, kuid nonsi asemel antakse allkiri kõigi eelnevate sõnumite räsile. Kuna sõnumid sisaldavad endas juhuarve, siis on ka nende räsi juhuslik.

Siin tuleb arvestada ka sertifikaatide kehtivuse kontrolli SSL/TLS seansis.

Veebis isiku tuvastamist tehakse näitekoodis veebivormil.

SSL/TLS taasläbirääkimise viga

2009. aastal tuvastati SSL/TLS protokollis viga, millega sai ühendustesse ründaja valitud teksti sisestada. [1][2] Selle tulemusena täiendati SSL/TLS spetsifikatsioonis taasläbirääkimist (renegotiation), ent need täiendused ei olnud tagasiühilduvad.[3] Seetõttu pole vanemad SSL/TLS kliendid ja ka veebilehitsejad suutelised taasläbirääkima täiendatud versiooni kasutava serveriga.

Kui algatada SSL/TLS seanss ilma kasutaja sertifikaati küsimata, s.t isikut tuvastamata, siis hiljem on selle tegemiseks vaja läbi viia taasläbirääkimised -- näiteks kui kasutaja külastab veebilehte, kasutades HTTPS-protokolli ning hiljem soovib end ID-kaardiga sisse logida, tuleb teha taasläbirääkimine. Vanemad veebilehitsejad seda aga uue protokolli kohaselt ei oska. Kui siiski on soov sellist olukorda võimaldada, tuleb luua kaks eraldiseisvat ühenduspunkti: esimene, mis teeb "puhast" SSL/TLSi, ja teine, mis küsib kasutaja sertifikaati.

Kui isikut tuvastav server on eraldiseisvas ühenduspunktis, siis sellega seanssi alustades küsitakse kasutajalt kohe isikutuvastuse sertifikaati ning hiljem taasläbirääkimisi pole vaja teha.

Eraldi ühenduspunktid peaksid olema erinevate IP-aadresside peal või vähemalt kasutama erinevat porti. Eraldi virtuaalhostidest ei piisa, kuna enne luuakse SSL/TLS seanss ning alles siis vaadatakse, millist virtuaalhosti kasutada.

Mobiil-ID-ga

Isikutuvastamine Mobiil-ID abil toimub järgmiselt:[4][5][6]

  1. Luuakse tavaline SSL/TLS seanss ilma kliendisertifikaati küsimata.
  2. Kasutaja sisestab oma telefoninumbri ja/või isikukoodi ning viimase välja andnud riigi koodi. Need andmed edastatakse teenusele DigiDocService MobileAuthenticate päringuga.
  3. DigiDocService kontrollib OCSP-protokolli vahendusel, et kasutaja Mobiil-ID isikutuvastuse sertifikaat kehtib.
  4. DigiDocService teeb samaaegselt järgmist:
    • Saadab mobiiloperaatorile isikutuvastuse päringu (mis edastab selle kasutaja telefonile);
    • Tagastab kontrollkoodi ja kasutaja sertifikaadi.
      • NB! Teenus tagastab kõigest tuvastamisel oleva isiku sertifikaadi -- see ei tähenda veel, et kasutaja oleks autenditud!
  5. Rakendus kuvab kasutajale neljakohalise isikutuvastuspäringu kontrollkoodi.
  6. Rakendus hakkab perioodiliselt käima DigiDocService'i käest isikutuvastuse olekut küsimas GetMobileAuthenticateStatus päringuga.
    • Olekupäring on võimalik teha ka sünkroonselt, s.t DigiDocService hoiab ühendust avatuna ning ei tagasta midagi enne, kui mobiiltelefonilt on tulnud vastus.
  7. Kasutaja telefonil kuvatakse teade isikutuvastuspäringu kohta
  8. Kasutaja veendub, et telefonil kuvatav kontrollkood langeb kokku rakenduse poolt kuvatavaga ning sisestab Mobiil-ID PIN1.
  9. Teenuse poolt saadetud väljakutse (challenge) allkirjastatakse SIM-kaardil oleva salajase võtmega ning tulemus saadetakse mobiiloperaatorile, mis edastab selle DigiDocService'ile.
  10. Järgmine kord, kui rakendus tuleb teenuselt päringu olekut küsima, vastab teenus, et kasutaja on autenditud ning tagastab allkirja.

Kasutamise näiteid näeb avalduste kasutusmallis ning SK näiterakenduse leiab siit.

Digitaalne allkirjastamine

Uusi digitaalseid allkirju luuakse kahes erinevas vormingus: DIGIDOC-XML ja BDOC. Esimest neist toetavad jdigidoc, libdigidoc, libdigidoccom; teist jdigidoc ja libdigidocpp (plaanitavalt ka .NET teek). Siit on näha, et ainus teek, mis mõlemat formaati toetab on jdigidoc, mistõttu soovitatakse seda kasutada ka uute arenduste tegemisel.[7] Ka DigiDocService toetab vaid DDOC vorminguid.[8]

Sõltumata allkirja vormingust on nii teekide kui ka DigiDocService puhul lähenemine sama:

  1. luuakse konteiner,
  2. lisatakse allkirjastatavad failid,
  3. üle andmete genereeritakse räsi,
  4. räsi allkirjastatakse osapoolte salajaste võtmetega,
  5. allkirjastaja sertifikaadile küsitakse kehtivuskinnitus (tühistusnimekirja kontrollimisest on vähe, vt Digiallkirjade andmine ja Sertifikaatide kehtivuse kontroll) ning
  6. allkiri ja kinnitus lisatakse konteinerisse.

Veebirakendustes allkirjastades toimub kõik allkirjastamise-eelne ning -järgne tegevus samamoodi nagu kohaliku allkirjastamise korral, ent räsi allkirjastamine (samm 4) toimub kliendi veebibrauseris. Selle jaoks on loodud JavaScripti teek, mille programmeerimisliides (API) on ühtne ning võimaldab erinevaid allkirjastamispluginaid – sõltumata kasutaja operatsioonisüsteemist ja brauserist – ühte moodi kasutada. Täpsem info siit.

Hiljem allkirja kontrollides tuleb veenduda, et konteineris olevate dokumentide räsid langevad kokku allkirjastatud räsidega ning allkirjad räsidel ja kehtivuskinnitustel on korrektsed (selleks kasutatakse allkirjastaja ning kehtivuskinnituse väljastaja sertifikaatidel olevaid avalikke võtmeid).

Selguse ja turvalisuse tagamiseks peab iga rakendus, kus on digiallkirjastamise funktsioon, vastama kahele nõudele:[9]

  1. Enne allkirjastamist peab kasutaja saama mõistlikul moel andmetega tutvuda.
  2. Pärast allkirjastamist saab kasutaja kontrollida, millele tema allkiri anti, ehk tal on ligipääs DigiDoc-konteinerile koos esialgsete allkirjastatud andmete ja allkirjadega.

Dokumentide digitaalset allkirjastamist on demonstreeritud nii eraldiseisva utiliidina kui ka avalduste esitamise kasutusmallis - nii veebis, kasutades DigiDocService-teenust või SWIG mähkurit, kui ka töölauarakenduses.

Allkirja kontrollimist on demonstreeritud eraldiseisvas rakenduses, avalduste rakenduses ja avaldusi töötlevas teenuses.

Mobiil-ID-ga

Mobiil-ID-ga saab allkirjastada dokumente kahte moodi:[4][5][6]

  1. Saadame DigiDocService-teenusele dokumendi, mispeale alustatakse uus seanss, kus luuakse ainult seda dokumenti sisaldav allkirjastatud konteiner, mis tagastatakse päringu esitajale. Selle jaoks tuleb kasutada päringuid MobileCreateSignature ja GetMobileCreateSignatureStatus. See on hea olukorras, kus meil ei ole DigiDocService vaja muuks kui dokumendi allkirjastamiseks.
  2. Allkirjastame olemasolevas seansis loodud konteineri päringutega MobileSign ja GetStatusInfo. Seda lähenemist tasub kasutada siis, kui DigiDocService seanssi kasutatakse ka muude operatsioonide tegemiseks ning konteineri Mobiil-ID-ga allkirjastamine on vaid üks osa sellest.

Üldiselt toimub Mobiil-ID-ga allkirjastamine samamoodi nagu isikutuvastamine, järgmiste erinevustega:

  • Teenusele ei saadeta MobileAuthenticate ja GetMobileAuthenticateStatus, vaid ülaltoodud päringud.
  • Teenusele saadetakse allkirjastatavad dokumendid või nende räsid ning Mobiil-ID allkirja küsitakse hoopis nende räsile, mitte väljakutsele.
  • Allkiri antakse digitaalallkirjastamise salajase võtmega, mitte isikutuvastamise omaga. Sellest tulenevalt kontrollib ning tagastab DigiDocService allkirjastamisertifikaadi ning kasutaja peab sisestama PIN2, mitte PIN1.

Nende toimingute tulemusel moodustab DigidocService-teenus allkirjastatud konteineri, mille rakendus saab alla laadida. Kui alguses saadeti teenusele vaid allkirjastatavate dokumentide räsid, siis lisasammuna peab konteineris asendama räsid dokumentide endiga.

Kasutamise näiteid näeb avalduste kasutusmallis ning SK näiterakenduse leiab siit.

Krüpteerimine

EID kontekstis toimub krüpteerimine vastavalt standardis XML Encryption Syntax and Processing esitatud põhimõtetele, et saata salastatud faile kindlatele adressaatidele. Küll kasutatakse DigiDoc-rakenduste spetsiifilist lähenemist, kus failid lisatakse enne krüpteerimist DIGIDOC-XML konteinerisse, mis võib, kuid ei pea olema allkirjastatud.

Andmed pannakse DDOC-konteinerisse, mis krüpteeritakse sümmeetrilise algoritmiga (128-bitise võtmega AES), andes tulemuseks CDOC-konteineri. Krüpteerimisel kasutatud võti krüpteeritakse saajate isikutuvastus­sertifikaatide avalike võtmetega ning tulemused lisatakse CDOC-konteinerisse. Samuti lisatakse sinna metaandmed krüpteeritud failide kohta, et kasutaja näeks, mis seal sees on. Kuna metaandmeid saavad näha kõik huvilised ilma konteinerit dekrüpteerimata, on soovitatav kasutada ettevaatust ja veenduda, et metaandmetesse ei satuks tundlikku teavet.

Konteineri kättesaamisel kasutab adressaat oma isikutuvastuse sertifikaadi salajast võtit, et saada kätte AES-võti, mille abil saab failid lahti krüpteerida.

Sellist krüpteerimist saab kasutada vaid lühiajaliselt, näiteks andmete transportimiseks. Kuna krüpteeritud andmeid saavad avada ainult saajateks märgitud isikud oma krüpteerimise ajahetkel kehtivate sertifikaatidega, siis ei sobi see lahendus pikaajaliseks arhiveerimiseks -- sertifikaatide aegumisel asendatakse need kasutaja kaardil uutega ning vana salajast võtit pole enam võimalik kasutada.[10] See aga muudab konteineri jäädavalt suletuks. Samuti tuleb meeles pidada, et ID-kaardi jaoks krüpteeritud konteinerit ei saa avada sama isik oma Digi-ID-ga.

Krüpteerimist toetavad teegid libdigidoc (ja seega ka libdigidoccom) ning jdigidoc. DigiDocService-teenust pole võimalik krüpteerimiseks kasutada, aga see poleks ka mõistlik, sest sel juhul tuleks salastatavad andmed enne saata SK-le. Krüpteerimist demonstreeritakse avaldusi töötlevas teenuses ning dekrüpteerimist avalduste rakenduses.

Tähelepanu: luues tarkvara, mis tegeleb andmete lahti krüpteerimisega, tuleb kindlasti silmas pidada rünnet täidistusoraaklile.

Sertifikaatide pärimine LDAP-ist

Selleks et transpordivõtit saaks krüpteerida saaja avalike võtmetega, on vaja viimased kusagilt hankida. Selleks tarbeks on Sertifitseerimiskeskusel LDAP-teenus, mille abil leiab[11]

  • SK sertifitseerijate sertifikaadid ja kehtivad tühistusnimekirjad,
  • kehtivad isikutunnistustele väljastatud sertifikaadid ning
  • kõik väljastatud asutuse sertifikaadid.

Teenus asub aadressil ldap.sk.ee. Suhtlemiseks tuleb kasutada protokolli LDAPv3; juurdepääs teenusele on vaba ja tasuta.[12]

Isikusertifikaadi leidmiseks tuleb päringusse sisestada täpne Common Name (kujul "perenimi,eesnimi,isikukood") või isikukood. Mustri järgi otsimine on keelatud. Näiteks (järgmised päringud ei tagasta midagi, kuna testsertifikaate nendes kataloogiharudes ei hoita—siin võib testimiseks kasutada enda isikukoodi):

# Linux
ldapsearch -x -h ldap.sk.ee -b ou=Authentication,o=ESTEID,c=EE "(cn=MÄNNIK,MARI-LIIS,47101010033)" userCertificate
ldapsearch -x -h ldap.sk.ee -b ou=Authentication,o=ESTEID,c=EE "(serialNumber=47101010033)" userCertificate

# Windows - kui sisestada järgmised päringud Internet Explorer'i aadressiribale, siis
#           käivitatakse Contacts rakendus, mille "IDs" saki alt leiab sertifikaadi(d)
ldap://ldap.sk.ee:389/ou=Authentication,o=ESTEID,c=EE??sub?(cn=MÄNNIK,MARI-LIIS,47101010033)
ldap://ldap.sk.ee:389/ou=Authentication,o=ESTEID,c=EE??sub?(serialNumber=47101010033)

Täpne kataloogistruktuur on nähtav SK repositooriumis.

Päringut esitades tuleb silmas pidada, et ühel isikul võib LDAP-is olla mitu erinevat sertifikaati (nt ID-kaart ja Digi-ID). Samuti tuleb silmas pidada, et LDAP pole turvaline, mistõttu on võimalik ründajal sertifikaat välja vahetada enda omaga ning alati tuleb tagastatud sertifikaat üle kontrollida: kellele see on väljastatud, kelle poolt jne.

Sertifikaatide kehtivuse kontroll

Sertifikaadi kehtivust tuleb eraldi kontrollida ka väljaandja käest; ei piisa vaid sertifikaadil oleva kehtivuse algus- ja lõppkuupäeva kontrollist, kuna sertifikaadi väljaandja võib selle teatud põhjustel varem kehtetuks tunnistada, peatada või peatamist lõpetada.

Märkus: Järgnev jutt kehtib vaid ID-kaardi ning Digi-ID puhul: Mobiil-ID sertifikaati kontrollib DigiDocService ning SSL/TLS seansis isikutuvastamine käib rakenduse tasemel.

Kehtivuse kontrolliks on kaks valikut:

  • Tühistusnimekiri (Certificate Revocation List) ehk CRL, mis on perioodiliselt allalaetav nimekiri kõikidest kehtetuks tunnistatud sertifikaatidest. AS Sertifitseerimiskeskuse tühistusnimekirjade kasutamine on tasuta.
  • Kehtivuskinnitus (Online Certificate Status Protocol) ehk OCSP, mis esitab päringu sertifikaadi kehtivuse kohta OCSP-serverile (edaspidi responder), mis annab vastuse reaalajas. AS Sertifitseerimiskeskuse kehtivuskinnituse teenuse kasutamine on tasuline.[13]

Kuigi tühistusnimekirjade kasutamine on tasuta ning neil on eelis käideldavuse osas (kui CRL-serverid muutuvad kättesaadamatuks, siis on ikkagi teada viimane kord allalaetud seis), ei ole nendes olev info reaalajaline esitus sertifikaatide kehtivusest. Värskeima kehtivusinfo saamiseks tuleb kasutada kehtivuskinnituse teenust, mis aga on tasuline ning responderi mitte-kättesaadavuse korral puudub igasugune info sertifikaatide kohta (ka mitte mõni hetk tagasi kehtinud). Iga veebiteenuse korral on vaja eraldi uurida nõudeid ning otsustada, kumb sobib paremini.

Tähelepanu: Tarkvaraarendajad on mõnikord kasutanud isikutuvastamise juures LDAP-teenust sertifikaatide kehtivuskontrolli vahendina. See on teenuse väärkasutus ja sellisena keelatud, isegi kui see (mõnikord) annab korrektseid tulemusi. LDAP-andmeedastus ei ole turvatud, mistõttu saab vastuseid võltsida või muuta, ning LDAP kataloog võib sisaldada ka kehtetuid sertifikaate.

SSL/TLS seansis

Eraldi teema on SSL/TLS seansi alguses kliendi antud ID-kaardi või Digi-ID sertifikaadi kehtivuse kontrollimine, kuna selle peaks läbi viima veebiserver, mitte -rakendus. Käesolev juhend käsitleb vaid Apache httpd ning Microsoft IIS servereid, kuigi see jutt võib rakenduda ka teistele.

Tühistusnimekirjade kasutamise korral töötab kõik hästi ning veebiserverid on suutelised neid iseseisvalt kasutama. Serveri konfigureerimiseks vaata näiteseadistust.

Kehtivuskinnituse kasutamisel on aga mõned lisatingimused, mida käsitlevad järgmised peatükid.

OCSP rakenduse tasemel

Kuigi nii Apache-l kui ka IIS-il on sisseehitatud vahendid OCSP kehtivuskinnituse küsimiseks, soovivad need, et vastuses oleks kaasas ka OCSP responderi sertifikaat. Viimast on vaja selleks, et saaks kontrollida vastusel olevat allkirja. Sertifikaadi lisamine on aga valikuline ning Sertifitseerimiskeskuse OCSP teenus seda ei tee. Seetõttu ei ole võimalik OCSP kehtivuskinnitust küsida vaikimisi vahenditega. Olemasolevatele seansihaldusvahenditele tuleb lisada tugi OCSP kehtivuskinnituse küsimiseks, et uue seansi alustades saaks veenduda, et kasutaja antud sertifikaat ikkagi kehtib.

Üks võimalus kehtivuse kontrolliks on kasutada DigiDocService meetodit CheckCertificate, mis tagastab parameetriks antud sertifikaadi OCSP staatuse. See on üks lihtsamaid lahendusi, ent nõuab ligipääsu DigiDocService-le (mis on tasuline) ning et veebirakenduses on vahendid SOAP-serveriga suhtlemiseks.

Alati on ka võimalik kasutada alternatiivseid vahendeid, mis suudavad suhelda Sertifitseerimiskeskuse OCSP-teenusega ning ei vaja selleks DigiDocService-i abi; neile tuleb aga responderi sertifikaat vastuse verifitseerimiseks käsitsi ette anda.

NB! Oma rakendustes peab alati OCSP-teenuse vastust verifitseerima, muidu on ründajal lihtne kehtivuskinnitust võltsida! Kui kasutada DigiDocService-teenust, siis see tehakse päringu käigus; alternatiivsete vahendite puhul peab seda suure tõenäosusega käsitsi tegema.

Näitekoodi DigiDocService-ga sertifikaadi kehtivuse kontrolliks leiab veebivormist ja OpenSSL-i kasutavaks alternatiiviks ID.ee näiterakendusest.

Autentimise OCSP

Sertifitseerimiskeskus pakub lisaks "tavalisele" OCSP teenusele ka autentimise OCSP teenust: see on mõeldud kasutamiseks süsteemidesse sisselogimisel. Autentimise OCSP ei kanna kehtivuskinnituse päringuid turvalogisse, mistõttu puudub hilisem tõestus sel hetkel kehtivuse kohta. Samuti on hinnakiri teistsuguse ülesehitusega: tasuma peab erinevate sertifikaatide eest, mille olekut päritakse, mitte päringute hulga eest. Seetõttu on ta sobilik väikese hulga kasutajatega süsteemide jaoks, ent mitte avalike veebiteenuste jaoks.[14]

Autentimise OCSP tagastab oma vastustes ka responderi sertifikaadi, nii et seda saab kasutada Apache ja IIS-i sisseehitatud OCSP-kehtivuskontrolli vahenditega. Seda tasub teha aga vaid tingimusel, kui eelmises lõigus mainitud hinnakirja eripärad on vastuvõetavad, kuna mitme unikaalse kasutaja korral võib teenus osutuda kallimaks tavalisest OCSP-st.

Autentimise OCSP-l puudub ka test-teenus, mistõttu tuleb arendamisel/testimisel saata päringuid live-responderile.

Isikuandmete faili kasutamine

ID-kaardile talletatud isikuandmete faili ei oska ükski DigiDoc teekidest lugeda. Sellepärast on tegu võrdlemisi madala taseme operatsiooniga, mida peab iga arendaja käsitsi tegema. Kuna olulisemad väljad isikuandmete failist (nimi, isikukood ning viimasest tuletatav info) on olemas ka sertifikaadi peal, siis üldjuhul piisab rakenduse jaoks sertifikaadi lugemisest, mida toetavad mitmed DigiDoc teegid.

Märkus: Digi-ID-l on küll isikuandmete fail olemas, et täidetud on vaid dokumendi number; isikukood koosneb tühikutest ning kõikidel teistel väljadel on üks 0-bait.

Kui aga siiski on vajadus isikuandmete faili lugeda, siis selle jaoks on vähe võimalusi. Tuleb kas kaardiga otse suhelda või kasutada mõnda teeki, mis seda minimaalsel määral abstraheerib (näiteks OpenSC). Viimasega on aga see probleem, et sellised teegid on enamasti vaid C jaoks ning nende kasutamine näiteks Javas või .NET-is on keerulisem kui kaardiga otse suhtlemine.

Mõnes kindlas olukorras võib piisata ka eidenv rakenduse kasutamisest -x võtmega.

Veebirakendustes kasutaja isikuandmeid lugeda ei saa, kuna uus veebilehitseja plugin seda ei võimalda.

Kaardiga otse suhtlemine

Eesti eID kiipkaartidega otse suhtlemiseks tuleb kaardile saata vajalikud baidijadad (Application Protocol Data Unit ehk APDU) ning lugeda vastuseid. Sõnumite formaat ning tähendused on paika pandud ISO/IEC 7816-4 standardis, mille viimase versiooni saab osta ISO käest, ent natukene aegunud variant on ka tasuta saadaval. Eesti eID kiipkaartide spetsiifika kohta saab lugeda EstEID-kaardi kasutusjuhendist.

Kuna sõnumite formaat on standardiseeritud, siis ei ole väga tõenäoline, et kirjutatud kood uuemate kaartidega enam ei toimiks. Ainus, mis saab juhtuda, on et uutel kaartidel muutub isikuandmete faili asukoht või et selles olevad andmed erinevad senistest kaartidest. Sellises olukorras tuleb ka OpenSC-d või muid teeke kasutav kood ümber kirjutada ning värskendada faili asukohta ning väljade tähendusi. (Samamoodi vajaks sellises olukorras ümberkirjutamist ka eidenv rakendus, ent selle eest kannaks hoolt selle haldaja.)

Baidijada, mida on isikuandmete faili lugemiseks vaja saata, on järgmised (kasutades T=0 protokolli):[15]

00 A4 00 0C          # Valime juurkataloogi
00 A4 01 0C 02 EE EE # Valime kataloogi EEEE
00 A4 02 04 02 50 44 # Valime faili 5044, mis sisaldab isikuandmeid
00 B2 XX 04          # Loeme isikuandmete failist kirje nr XX (vt tabelit)
                     # Kaart vastab 61 YY, kus YY tähistab, mitu baiti ootavad lugemist
00 C0 00 00 YY       # Loeme kaardilt YY baiti
                     # Kaart vastab ... 90 00, kus ... on soovitud andmed ning 90 00 tähistab OK staatust
Kirje number Sisu Maksimaalne pikkus baitides
1 Perenimi 28
2 Eesnime rida 1 15
3 Eesnime rida 2 15
4 Sugu 1
5 Kodakondsus 3
6 Sünnikuupäev (pp.kk.aaaa) 10
7 Isikukood 11
8 Dokumendi number 9
9 Kehtivuse viimane päev (pp.kk.aaaa) 10
10 Sünnikoht 35
11 Väljaandmise kuupäev (pp.kk.aaaa) 10
12 Elamisloa tüüp 50
13 Märkuste rida 1 50
14 Märkuste rida 2 50
15 Märkuste rida 3 50
16 Märkuste rida 4 50

Kui kasutada kaardiga suhtlemiseks mõnda teeki, siis on võimalik, et viimast sammu ei ole vaja teha. Näiteks kasutades javax.smartcardio klasse saame baidijadale 00 B2 XX 04 vastuseks ResponseAPDU objekti, mille getData() meetod tagastab soovitud andmed ning getSW() tagastab staatuse.[16] Seega pole vaja käsitsi saata sõnumit 00 C0 00 00 YY.

Näidet isikuandmete lugemisest on võimalik näha avalduste rakenduses.

Tehnoloogia ja arendusvahendid

Jaotis sisaldab üldist teavet, mida saab ära kasutada ning mida arendajad peaksid teadma sõltumata sellest, kas eesmärk on olemasolevate rakenduste täiendamine või uute rakenduste arendamine.

Sertifikaadid

AS Sertifitseerimiskeskus kasutab kolmetasemelist sertifitseerimisahelat:[17]

  • tipmised sertifikaadid (Juur-SK ja EE Certification Centre Root CA)
  • sertifitseerimise sertifikaadid (nt ESTEID-SK 2011, mis antakse välja tipmise sertifitseerija poolt)
  • lõppkasutaja sertifikaadid (nt ID-kaardile kantavad isikusertifikaadid, mis antakse välja ESTEID-SK 2011 alt).

Juur-SK on vanema sertifitseerimisahela tipmine ahel, mis aegub 2016. aastal. Alates 2011. aasta juulist on kasutusel uus ahel, mille tipmiseks sertifikaadiks on EE Certification Centre Root CA.[18]

Ühe märkimisväärse erinevusena anti Juur-SK ahelas kehtivuskinnituse teenuse (OCSP-responder) sertifikaadid välja sertifitseerija ehk teise taseme sertifikaatide alt. EECCRCA ahelas antakse kehtivuskinnituse teenuse sertifikaadid välja aga otse juursertifikaadi alt.[17]

ID-kaardi, elamisloakaardi ning Digi-ID isikusertifikaadid on välja antud sertifitseerimise sertifikaadi ESTEID-SK, ESTEID-SK 2007 või ESTEID-SK 2011 alt, sõltuvalt väljastamise hetkest. Sertifikaadi organisatsiooniks (O) on märgitud kas "ESTEID" või "ESTEID (DIGI-ID)" ning organisatsiooni üksuseks (OU) "authentication" või "digital signature" vastavalt sellele, kas tegu on isikutuvastus või allkirjastamissertifikaadiga. Samuti on sertifikaatidel laiendid põhikasutusvaldkonna (keyUsage) ning lisakasutusvaldkondade (extKeyUsage) määramiseks: isikutuvastussertifikaadil on põhikasutusvaldkonnaks DigitalSignature, KeyEncipherment ja DataEncipherment ning lisakasutusvaldkonnaks ClientAuthentication ja SecureEmail, allkirjastamissertifikaadil on põhikasutusvaldkonnaks ainult NonRepudiation ning lisakasutusvaldkonnad puuduvad.

Tähelepanu: Isikutuvastussertifikaadi küljes olev DigitalSignature lipp ei tähenda, et sellega saaks anda seaduslikult siduvaid allkirju -- seda näitab allkirjastamissertifikaadi küljes olev NonRepudiation lipp.

Täpsemat infot sertifikaatide profiilide kohta leiab sk.ee lehelt.

Kõik SK sertifikaadid on kättesaadavad nende kodulehelt.

Failivormingud

Järgnevalt on kirjeldatud kolm Eestis kasutatavat eID dokumentidega seotud failivormingut.

DDOC

DigiDoc failivorming on standardi ETSI 101 903 (XML Advanced Electronic Signatures – XAdES) profiil "XAdES-X-L". Antud standard kirjeldab digitaalallkirjastatud dokumentide struktuuri ning profiil võimaldab allkirjaga siduda järgnevad allkirjastatavad atribuudid:[19]

  • Allkirjastamiseks kasutatav sertifikaat
  • Allkirjastamise aeg
  • Allkirjastamise asukoht
  • Allkirjastaja roll või resolutsioon
  • OCSP serveri sertifikaat
  • OCSP vastus

DigiDoc konteiner on sisuliselt XML-dokument, mille elementideks on algfailid või nende asukohad ning räsid, failidega seotud allkirjad ja igas allkirjas sisalduvad allkirjastaja sertifikaat, kehtivuskinnitus ja kehtivuskinnituse teenuse sertifikaat.

DigiDoc failivormingu versioon 1.0 kandis nime SK-XML, kuid kõik järgnevad kannavad nime DIGIDOC-XML. Failivormingu versioon on kirjutamise hetkel 1.3. Täpsed vormingukirjeldused leiab id.ee lehelt.

Kõik seda vormingut järgivad allkirjastatud konteinerid kannavad laiendit .ddoc.[19]

BDOC

BDOC on uus digitaalallkirja vorming, mis on loodud selleks, et asendada Eesti-spetsiifiline DDOC digitaalallkirja vorming.

Oluline muudatus võrreldes DDOC-iga on see, et .bdoc faili näol on tegu ZIP-konteineriga, mis sisaldab allkirjastatud faile, allkirju ja juhtinfot ning mida saab põhimõtteliselt avada suvalise ZIP-formaati tundva programmiga. Tänu selle on seal sees olevad failid lihtsalt loetavad - erirakendusi nagu DigiDoc klient on vaja ainult algfailide tervikluse ja allkirjade kontrollimiseks.

Kuna ZIP on pakitud vorming, võivad BDOC-vormingus failid olla DDOCist oluliselt väiksemad. Lisaks on BDOC-failide meili teel edastamine paremini toetatud, kuna DDOC-vormingus dokumentide edastamisel on esinenud probleeme (osad meiliserverid filtreerisid DDOC-vormingus manused välja).[20]

Täpsemat tehnilist infot hetkel kasutuses oleva BDOC-vormingu kohta saab lugeda Eesti standardidokumendist [1].

Eestis vaikimisi eelistatud allkirjastamistarkvara standard on orienteeruvalt 2016. aastaks BDOC. Selle failivormingu tugi loodi eID baastarkvarasse 2013. aastal. Alates jaanuarist 2015 hakkavad ID-tarkvara klientrakendused automaatselt kasutama BDOC failivormingut. Valikuna säilib ka DDOC, kuid seda üleminekuperioodiks. 2015/2016 DDOC formaadi loomise tugi kaob ID-kaardi baastarkvarast, säilub verifitseerimise tugi. Ajakohane info BDOC-vormingu kohta on kättesaadav aadressilt http://www.id.ee/bdoc.

CDOC

CDOC-vormingu puhul järgitakse XML Encryption Syntax and Processing (XML-ENC) standardis väljatoodud struktuuri. Krüpteerimise kohta saab rohkem lugeda krüpteerimise peatükist.

Konteineriks on XML-dokument juurelemendiga EncryptedData - selle sees on:

  • krüpteerimisalgoritmi AES-128-CBC identifikaator,
  • sümmeetriline võti krüpteeritud kujul (iga vastuvõtja jaoks eraldi):
    • krüpteerimisalgoritmi RSA 1.5 identifikaator,
    • vastuvõtja nimi,
    • vastuvõtja sertifikaat (mille avalikku võtit kasutati krüpteerimiseks),
    • võti krüpteeritud kujul
  • sisalduvate andmete metainfo:
    • algfaili nimi,
    • faili suurus,
    • faili MIME tüüp,
  • algandmed krüpteeritud kujul.

Kuigi XML-ENC toetab suvalise hulga failide krüpteerimist, kasutatakse DigiDoc rakendustes lähenemist, mille korral pannakse kõik algfailid DDOC-konteinerisse ning siis krüpteeritakse see üks fail.

Arendusvahendid

Java, C++, PHP ning JavaScripti jaoks leidub palju tasuta arendusvahendeid ning tõenäoliselt on igal arendajal juba oma lemmikud välja kujunenud. Raskem on aga .NET puhul, kus -- kui ei soovita kasutada Mono vms -- on ainsaks arendusvahendite pakkujaks Microsoft. Kuna ei saa eeldada, et igal arendajal või arendushuvilisel on võimalus osta Windowsi ja arendusvahendite litsentsid, siis on alljärgnevalt toodud legaalsed võimalused nende tasuta proovimiseks.

Soovitatav operatsioonisüsteem on Windows 7 põhjusel, et Windows XP tugi lõpeb täielikult 8.04.2014, aga Windows 7'l 14.01.2020.

DigiDoc tarkvara

AS Sertifitseerimiskeskus pakub veebiteenust ning mitmeid teeke nimega DigiDoc, mis on loodud eID dokumentide kasutamise lihtsustamiseks.

Teegid

Töölauarakendustes eID funktsionaalsuse kasutamiseks on loodud neli erinevat teeki:[21]

  • jdigidoc - Java teek, mis on ühtlasi ka esmane soovitus uute arenduste tegemisel.
    Toetatud vormingud: DDOC, BDOC, CDOC.
  • libdigidoc - C teek, millelt on plaan tugi asenduse tekkimisel ära kaotada. Ei ole soovitatud uute arenduste tegemisel.
    Toetatud vormingud: DDOC, CDOC.
  • libdigidocpp - C++ teek, mis on kasutuses DigiDoc3 kliendi koosseisus. Eraldiseisvana teda arendajatele ei pakuta, ent on kättesaadav koos kliendiga.
    Toetatud vormingud: BDOC.
  • libdigidoccom - COM liides libdigidoc teegile. Ei toeta krüpteerimist.
    Toetatud vormingud: DDOC.
  • ndigidoc - .NET teek krüpteerimiseks ja dekrüpteerimiseks. Hetkel toetab ainult tarkvaralisi võtmepaare, s.t ID-kaarti kasutada ei saa; saaja salajane võti peab olema kõvakettal PKCS#12-tüüpi konteineris.
    Toetatud vormingud: CDOC.

Tulevikus on plaanis luua ka .NET teek, mis asendaks COM teegi.[21]

Teekide paigaldamiseks külasta Digidoc teekide lehte (Windows) või seadista endale RIA tarkvararepositoorium (Fedora, openSUSE, Ubuntu).

DigiDocService

Alternatiiviks teekide kasutamisele on olemas ka DigiDocService, mis on SOAP-põhine tasuline veebiteenus. See võimaldab isikutuvastuse, digitaalallkirjastamise ja allkirjade kontrollimise funktsionaalsust siduda teiste infosüsteemidega. Teenust on võimalik kasutada erinevatelt arenduskeskkondadelt/platvormidelt, millel on SOAP 1.0 RPC-encoded tugi.

Teenuse poolt pakutav funktsionaalsus:

  • Isikusamasuse kontroll Mobiil-ID'ga
  • Sertifikaatide kehtivuse kontroll (võimaldab isikusamasuse kontrolli ID-kaardi ja muu kiipkaardiga)
  • DigiDoc failide moodustamine
  • Digitaalallkirjastamine Mobiil-ID'ga
  • Digitaalallkirjastamine ID-kaardi (ja muu kiipkaardiga)
  • Digitaalallkirjastatud failide (DigiDoc) sisu ja allkirjade kehtivuse kontroll.

DigiDocService toetab ainult DDOC formaadis allkirjastatud dokumente - BDOC tugi hetkel puudub.

Teenusele ligipääsu võimaldatakse IP aadressi põhiselt, selle kasutamiseks tuleb rakenduse pakkujal sõlmida leping AS Sertifitseerimiskeskusega. Teenuse kasutamise maksumus sõltub allkirjastamise ja autentimise päringute arvust kuus ja ühelt rakenduselt tulevatest üheaegsete päringute arvust.[22]

Mobiil-ID

Mobiil-ID on kasutatav ainult läbi DigiDocService'i -- seega võib tekkida vajadus seni sellest sõltumatule teenusele DigiDocService tugi lisada. Samuti ollakse sellega kaasnevalt sunnitud usaldama teenusepakkujat. Vastutasuks on arendamise lihtsus -- implementatsiooni detailid ning mobiilioperaatoritega suhtlemine on arendaja eest peidetud ning Mobiil-ID kasutamiseks piisab mõne parameetri andmisest DigiDocService-teenusele.

Mobiil-ID protokoll on asünkroonne, s.t esitatud päringule ei tule kohe vastus, vaid seda on vaja käia hiljem eraldi küsimas; kuna Mobiil-ID päringute käigus peavad kasutajad koode verifitseerima ning PIN-e sisestama, mis võib võtta omajagu aega, siis on otstarbekas võrguühenduse ressursid vahepeal vabastada. Seega kutsutakse esiteks välja päringumeetod ning seejärel käiakse perioodiliselt olekut kontrollimas.[5]

Mobiil-ID ülevaadet näeb eID lühitutvustuses ning kasutamise näiteid avalduste kasutusmallis.

Testteenus

Testimiseks ja arendamiseks on olemas ka tasuta OpenXAdES testkeskkond.[23]

Testkeskkonnas on võimalik kasutada Mobiil-ID testtelefoninumbreid, et vältida mobiilivõrkude kasutamist arendamisel. Kasutades testteenust, peab rakenduse nimeks (meetodite parameeter ServiceName) alati panema "Testimine".[24] Alternatiivina võib enda Mobiil-ID-d toetava telefoninumbri OpenXAdES-es registreerida ning testimisel seda kasutada.

Teek/teenus DDOC BDOC CDOC
jdigidoc X X X
libdigidoc X X
libdigidocpp X
libdigidoccom X
ndigidoc X
DigiDocService X

Testimisvahendid

AS-ist Sertifitseerimiskeskus saab tellida testotstarbelisi ID-kaarte, digi-IDsid ja digitempleid (eToken krüptopulgal). Digitempli puhul on võimalik tellida kohandatud väärtustega subjektiväli (CN, Common Name). Hinnakirja ning täpsustava teabe leiab SK testkaartide lehelt.

Testkaartide kasutamiseks tuleb paigaldada ka testsertifikaadid: Windowsis on selleks testsertifikaatide pakk ning Linuxis kas esteidcerts-dev või esteidcerts-devel pakk (olenevalt pakihaldurist).

Isikuandmete faili kasutamine

Infoturbe koosvõime raamistik [25] sätestab: ID-kaardi isikuandmete fail sisaldab sama informatsiooni, mis on kaardile kantud visuaalselt. See sisaldab kaardiomaniku nime, kaardi kehtivuse aega ja muud sarnast. Oluline on, et see sisaldab ka kaardiomaniku isikukoodi. Kui omanik sisestab kaardi kiipkaardilugejasse, on süsteemil võimalik sealt kiirelt välja lugeda isikukood ja kasutada seda oma edasistes toimingutes.'

Isiku tuvastamist ID-kaardi isikuandmete faili abil on mõistlik kasutada kohtades, kus on võimalik ka visuaalne isikutuvastamine (näiteks piiri ületamisel).

Digi-ID sisaldab vaid isikuandmete failis vaid dokumendinumbrit -- ülejäänud väljad on täitmata.

ID-kaardil sisalduvad andmed

Allolevaid andmeid saab lugeda ilma PIN-koodi sisestamata (piisab, kui kaart on lugejas).

Omaniku andmed:

  • eesnimi
  • keskmine nimi
  • perekonnanimi
  • sünnipäev
  • sünnikoht
  • isikukood
  • kodakondsus
  • sugu
  • elamisloa tüüp

ID-kaardi enda kohta saab lugeda järgmiseid andmeid:

  • ID-kaardi seerianumber
  • ID-kaardi aegumise aeg
  • ID-kaardi väljaandmise aeg

Kaardi üheseks indentifitseerimiseks on võimalik kasutada infot failist FID=EEEE/5044 (Personal Data File).[26]

Isikuandmete faili kasutamine veebis

Uue Digidoc-pluginaga pole võimalik lugeda ID-kaardilt isikuandmete faili. Ainus võimalus faili lugemiseks (SK kommentaar 31.05.12) on kasutades ID-kaardi tarkvaraga kaasasolevat utiliiti eidenv.exe. Seetõttu rakendusjuhend seda alamteemat ei käsitle.

eID abirakendused: eidenv, cdigidoc, digidoc-tool, jdigidoc

eidenv

Käsurea rakendus eidenv kuvab kaardil olevad isikuandmed, asendades endist IDUtil rakendust. Seda levitatakse OpenSC tarkvara koosseisus ning on ka ID-kaardi baastarkvara pakis. eidenv lähtekood on saadaval aadressil: http://www.opensc-project.org/opensc/browser/OpenSC/src/tools/eidenv.c

Kasutades -x võtit käivitab argumendiks antud programmi keskonnas, kuhu on lisatud ESTEID_* muutujad samade andmetega. Näiteks test-ID-kaardil on nendeks:

$ eidenv -x /usr/bin/printenv
...
ESTEID_SURNAME=MÄNNIK
ESTEID_GIVEN_NAMES1=MARI-LIIS
ESTEID_GIVEN_NAMES2=
ESTEID_SEX=N
ESTEID_CITIZENSHIP=EST
ESTEID_DATE_OF_BIRTH=01.01.1971
ESTEID_PERSONAL_ID=47101010033
ESTEID_DOCUMENT_NR=AS0010876
ESTEID_EXPIRY_DATE=01.02.2017
ESTEID_PLACE_OF_BIRTH=EESTI / EST
ESTEID_ISSUING_DATE=01.02.2012
ESTEID_PERMIT_TYPE=
ESTEID_REMARK1=
ESTEID_REMARK2=
ESTEID_REMARK3=
ESTEID_REMARK4=

Tänu selle on võimalik luua erinevaid isikuandmeid kasutavaid rakendusi ilma, et oleks vaja kaardiga otse suhelda -- need kasutavad lihtsalt vastavat keskkonnamuutujat. Sellist rakendust on aga väga lihtne ära petta, kuna väärtuste allikat ei saa kontrollida. Seetõttu on selline lähenemine sobilik vaid kinnistes ning teenusepakkuja kontrolli all olevates keskkondades.

Et saada rohkem infot rakenduse kohta, tuleb see käivitada -h või --help võtmega.

cdigidoc, digidoc-tool, jdigidoc

cdigidoc, digidoc-tool ning jdigidoc (mitte segi ajada jdigidoc-teegiga) on rakendused, mis lubavad teha põhilisi eID toiminguid. Kõik need demonstreerivad omalt poolt kasutatava teegi (vastavalt libdigidoc, libdigidocpp ning jdigidoc) võimalusi ning on heaks näitekoodi allikaks.

Et saada juhendeid rakenduse kasutamiseks, piisab nende käivitamisest ilma käsureavõtmeteta, mille peale kuvatakse abitekst. Cdigidoc'i ning jdigidoc'i rakendustest saab rohkem lugeda ka vastava teegi dokumentatsioonist.[27][28]

eToken-krüptopulga kasutamine

Kirjutamise hetkel on eToken-krüptopulk SK poolt toetatud ainult Windows-keskkonnas ning kõik vajalik allalaetav aadressilt: https://installer.id.ee/media/SafeNetAuthenticationClient_8_1_SP1Windows.zip.

Linux jt platvormid on SK poolt testimata ja toetamata, kuid vastavaid eTokeni draivereid on nad nõus teadlikule kasutajale jagama. Konteiner, mis sisaldab kõike vajalikku Linuxile koos dokumentatsiooniga on allalaetav aadressilt: https://installer.id.ee/media/SafeNetAuthenticationClient_Linux_8.1.zip. Tarkvara sõltub ka Hardware Abstraction Layer'ist (HAL), ent seda pole pakkide sõltuvuseks seatud. HAL on aga aegunud ning pole enam paljudes operatsioonisüsteemides vaikimisi paigaldatud: seetõttu võib olla vajalik libhal1 pakk käsitsi paigaldada.

Toetatud tarkvara:

  • Red Hat Enterprise 5.4 (32-bit and 64-bit) on 2.6 kernel
  • CentOS 5.4 (32-bit and 64-bit) on 2.6 kernel
  • SUSE Linux Enterprise 11 (32-bit and 64-bit) on 2.6 kernel
  • Fedora 11 (32-bit)
  • Fedora 12 (32-bit)
  • Ubuntu 9.10 (32-bit)
  • Ubuntu 10.04 (32-bit and 64-bit) on 2.6 kernel

Pakid sisaldavad endas mitmeid utiliite, ent oluliseimaks on seal leiduvad draiverid ning PKCS#11 moodulid. Viimaste asukohad on %SYSTEMROOT%\System32\eToken.dll (Windows) ning /lib/libeToken.so.8 (Linux; lõpus olev number sõltub versioonist) -- neid läheb vaja, kui on soovi PKCS#11 API kaudu digitempliga suhelda.

ID-kaardi @eesti.ee meiliaadressi kasutamine

ID-kaardi autentimissertifikaadis sisaldub ka riigi poolt kaardiomanikule omistatav eluaegne meiliaadress kujul Eesnimi.Perenimi@eesti.ee; juhul, kui sama ees- ja perenimega isikuid on mitmeid, saavad järgnevad isikuid aadressi kujul Eesnimi.Perenimi.N@eesti.ee, kus N on järjenumber. Enne 2005. aastat väljaantud sertifikaatidel on meiliaadressid kujul Eesnimi.Perenimi_XXXX@eesti.ee, kus XXXX on juhuslikult genereeritud neljakohaline arv. Uue sertifikaadi saamisel uuendatatakse see ära, ent eelmised kujud jäävad samuti kehtima.

@eesti.ee aadressi omapära on see, et kuna ta on ainus, mida sertifikaatidele kantakse, siis on ta ka ainus aadress, kuhu saab saata osade standardite (nt S/MIME) kohaselt krüpteeritud kirju.

Tegu on vaid edastusaadressiga -- kodanik peab seadistama eesti.ee portaalis oma päris postkasti aadressi, kuhu @eesti.ee aadressile saadetud kirjad edastatakse. Samuti on tal võimalus keelata kõik signeerimata ja/või krüpteerimata kirjad. Seetõttu ei saa kindel olla, et sellele aadressile saadetud kirjad ka kohale jõuavad ning tasub kasutaja käest meiliaadress üle küsida.

Meiliaadressi haldamisega on seotud ka X-tee päringud, mida kirjeldab vastav Riigiportaali lehekülg.

Tehnilised märkused ja tähelepanekud

Viga enne 2011. aastat välja antud kaartidega

Enne 2011. aastat välja antud ID-kaartidega, s.t 1024-bitiste võtmetega ei ole võimalik krüpteerida rohkem kui 384 bitti (48 oktetti), kuigi PKCS #11 standardi kohaselt peaks olema võimalik krüpteerida kuni 936 bitti (117 oktetti). Muuhulgas tähendab see ka seda, et andmeid allkirjastades tuleb kasutada räsialgoritmi, mille väljund oleks ülimalt 384 bitti -- nt DigiDoc-teekides kasutatakse sellel põhjusel läbivalt SHA-224 algoritmi.

Rünne täidistusoraaklile

2012. aastal tõhustati rünnet, mis töötab mitmel laialtlevinud krüptograafiaseadmel, s.h Eesti eID dokumentidel. Selle ründe käigus on võimalik eID dokumendil olevale sertifikaadile krüpteeritud teksti lahti krüpteerida või luua isikutuvastusallkiri (selle ründega seaduslikult siduvat allkirja ei saa võltsida). See tähendab, et rünne toimib ainult esimese, isikutuvastusvõtmepaari vastu. Rünne töötab, kuna Eesti eID dokumendid kasutavad PKCS#1 v1.5 täidist (padding).[29]

Rünne toimib ainult siis, kui eksisteerib rünnatavat eID dokumenti kasutav täidistusoraakel (padding oracle). Täidistusoraakel on osapool, kes võtab ründaja käest vastu mingi sõnumi, üritab seda endaga seotud eID dokumendiga lahti krüpteerida ning vastab, kas see õnnestus või ei (ning mitte midagi enamat -- oraakel ei tagasta lahti krüpteeritud sõnumit). Oraakliks võib olla näiteks mõni kasutaja arvutis jooksev mitte-pahatahtlik tarkvara (kui tegu oleks kahjurvaraga, siis saaks ID-kaarti palju lihtsamalt rünnata), mõni veebiteenus (kui rünnatakse teenusepakkuja digitemplit) vms.

Ründaja saab kasutada oraaklilt saadud vastust, et oraakli eID dokumendile suunatud teksti lahti krüpteerida või võltsida isikutuvastusallkirja. Enne 2011. aastat väljaantud ID-kaartidega kulub selleks keskmiselt vastavalt 11,5 tundi ja 49 000 oraaklipäringut (mediaaniga 3,5 tundi ja 14 500 päringut) või 48 tundi ja 203 000 päringut (mediaaniga 30 tundi ja 126 500 päringut). Uuemate kaartidega kulub keskmiselt vastavalt 27 tundi ja 28 300 päringut (mediaaniga 10 tundi ja 10 800 päringut) või 103 tundi ja 109 000 päringut (mediaaniga 65 tundi ja 69 000 päringut).[29]

Kirjutamise hetkel ei ole selline rünne aga teostatav, kuna ei leidu sobivaid oraakleid. Siinkohal tulebki arendajatel ettevaatlik olla, et nad ei kirjutaks tarkvara, mis täidaks eespool toodud tingimusi -- ründe jaoks piisab sellest, et tarkvara vastab, kas lahti krüpteerimine õnnestus või ei.

Kaks ründe autorit, Yusuke Kawamoto and Joe-Kai Tsay, käisid oma tööd ka Eestis esitlemas ning video sellest on nähtav UTTV-s.

USB õigused

Linuxi all sõltub pcscd pakk libccid pakist, mis paigaldab ka vajalikud udev reeglid, et pcscd deemon saaks kaardilugejatega suhelda. Kuigi enamasti töötab kõik hästi, võib juhtuda, et deemon siiski ei saa vajalikke õiguseid.

Lihtsaim lahendus sellest mööda saamiseks on käsitsi vajalike õiguste andmine. Selleks tuleb teada saada, mis siinil kaardilugeja on ning mis on selle seadmenumber.

$ lsusb
...
Bus 002 Device 003: ID 058f:9520 Alcor Micro Corp. EMV Certified Smart Card Reader

Ehk käesoleval juhul on kaardilugeja siinil 2 seade number 3. Seega tuleb teha:

# chown :pcscd /dev/bus/usb/002/003
# chmod g+w /dev/bus/usb/002/003

Selle tulemusena peaks ls -l kuvama crw-rw-r-- 1 root pcscd ... 003.

See lahendus küll töötab, ent pole väga hea—näiteks seadmenumbri muutudes kaovad õigused ära. udev või mõni analoogne automaatne vahend on parem, ent eelolev lahendus on pakutud juhuks, kui muu on välistatud.

Java ja libpcsclite

Java üritab kaardilugejatega töötamiseks kasutada /usr/lib/libpcsclite.so, mis Debiani/Ubuntu peal pole selles kohas. Asja töötamiseks tuleb luua sümlink:[30]

sudo ln -s /lib/libpcsclite.so.1 /usr/lib/libpcsclite.so      # Ubuntu
sudo ln -s /usr/lib/libpcsclite.so.1 /usr/lib/libpcsclite.so  # Debian

Välised viited

Siinkohal on välja toodud mitmed viited ning olemasolevad näiterakendused, mis on abiks eID arendajatele.

Lisaks aitab DigiDoc teekide, SK teenuste või ID-kaardi arendajate küsimustele vastuseid leida SK klienditugi abi@id.ee.


Allikaviited

  1. http://www.theregister.co.uk/2009/11/05/serious_ssl_bug/
  2. http://www.theregister.co.uk/2009/11/14/ssl_renegotiation_bug_exploited/
  3. http://tools.ietf.org/html/rfc5746
  4. 4,0 4,1 http://www.id.ee/index.php?id=30389
  5. 5,0 5,1 5,2 http://www.sk.ee/upload/files/DigiDocService_spec_est.pdf
  6. 6,0 6,1 http://www.sk.ee/upload/files/DigiDocService_spec_eng.pdf
  7. http://id.ee/index.php?id=30290
  8. http://id.ee/index.php?id=30291
  9. http://id.ee/index.php?id=31039
  10. http://id.ee/index.php?id=30264
  11. https://www.sk.ee/repositoorium/ldap/
  12. https://www.sk.ee/repositoorium/ldap/ldap-kataloogi-kasutamine/
  13. http://www.sk.ee/teenused/kehtivuskinnituse-teenus/
  14. https://www.sk.ee/teenused/kehtivuskinnituse-teenus/autentimise-ocsp/
  15. EstEID turvakiibi rakenduse kasutusjuhend. http://id.ee/public/EstEID_kaardi_kasutusjuhend.pdf
  16. http://docs.oracle.com/javase/7/docs/jre/api/security/smartcardio/spec/javax/smartcardio/CardChannel.html#transmit%28javax.smartcardio.CommandAPDU%29
  17. 17,0 17,1 http://www.id.ee/index.php?id=35764
  18. http://www.id.ee/index.php?id=30372
  19. 19,0 19,1 http://id.ee/index.php?id=30289
  20. http://www.id.ee/?id=34070
  21. 21,0 21,1 http://id.ee/index.php?id=30290
  22. http://id.ee/index.php?id=30291
  23. http://id.ee/index.php?id=30340
  24. https://www.openxades.org/dds_test_phone_numbers.html
  25. Infoturbe koosvõime raamistik. 2007. http://www.riso.ee/et/files/InfoturbeRaamistik.odt
  26. Teadmistebaas: administraatoritele. http://www.id.ee/index.php?id=30571
  27. http://id.ee/public/SK-CDD-PRG-GUIDE.pdf
  28. http://id.ee/public/SK-JDD-PRG-GUIDE.pdf
  29. 29,0 29,1 R. Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J. Tsay. Efficient Padding Oracle Attacks on Cryptographic Hardware. Cryptology ePrint Archive, Report 2012/417. http://eprint.iacr.org/2012/417
  30. http://www.opensc-project.org/opensc/wiki/FrequentlyAskedQuestions#Q:IhaveasmartcardreaderinstalledbutaJavaapplicationdoesnotseeit