Erinevus lehekülje "Uute eID rakenduste loomine" redaktsioonide vahel

Allikas: eid.eesti.ee
Jump to navigation Jump to search
(→‎eidenv: täpsustus)
10. rida: 10. rida:
 
* '''libdigidoc''' - C teek, millelt on plaan tugi asenduse tekkimisel ära kaotada. Ei ole soovitatud uute arenduste tegemisel.<br />Toetatud vormingud: '''DDOC''', '''CDOC'''.
 
* '''libdigidoc''' - C teek, millelt on plaan tugi asenduse tekkimisel ära kaotada. Ei ole soovitatud uute arenduste tegemisel.<br />Toetatud vormingud: '''DDOC''', '''CDOC'''.
 
* '''libdigidocpp''' - C++ teek, mis on kasutuses DigiDoc3 kliendi koosseisus. Eraldiseisvana teda arendajatele ei pakuta, ent on kättesaadav koos kliendiga.<br />Toetatud vormingud: '''BDOC'''.
 
* '''libdigidocpp''' - C++ teek, mis on kasutuses DigiDoc3 kliendi koosseisus. Eraldiseisvana teda arendajatele ei pakuta, ent on kättesaadav koos kliendiga.<br />Toetatud vormingud: '''BDOC'''.
* '''libdigidoccom''' - <abbr title="Component Object Model">COM</abbr> liides libdigidoc teegile.<br />Toetatud vormingud: '''DDOC'''.
+
* '''libdigidoccom''' - <abbr title="Component Object Model">COM</abbr> liides libdigidoc teegile. Ei toeta krüpteerimist.<br />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 [http://www.rsa.com/rsalabs/node.asp?id=2138 PKCS#12]-tüüpi konteineris.<br />Toetatud vormingud: '''CDOC'''.
 
* '''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 [http://www.rsa.com/rsalabs/node.asp?id=2138 PKCS#12]-tüüpi konteineris.<br />Toetatud vormingud: '''CDOC'''.
  

Redaktsioon: 28. september 2012, kell 14:34

Uute eID rakenduste loomine

Uute rakenduste loomise osas vajavad käsitlemist: digiallkirjastamine, krüpteerimine (piirame end CDOC-iga), isikutuvastamine veebis (siia alla ka OCSP, CRL, LDAP), isikuandmete faili kasutamine, DigidocService kasutamine.

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:[1]

  • 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.[1]

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.[2]

Testteenus

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

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".[4] Alternatiivina võib enda Mobiil-ID-d toetava telefoninumbri OpenXAdES-es registreerida ning testimisel seda kasutada.

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.[5]

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. Tänu selle on ta sobilik väikese hulga kasutajatega süsteemide jaoks, ent mitte avalike veebiteenuste jaoks.[6]

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.

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 allkirjastamiseks.
  3. Kasutaja lukustab lahti kaardil oleva 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 küsib sertifikaadi kohta kehtivuskinnitust.

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.

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. [7][8] Selle tulemusena täiendati SSL/TLS spetsifikatsioonis taasläbirääkimist (renegotiation), ent need täiendused ei olnud tagasiühilduvad.[9] 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.

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.[1] Ka DigiDocService toetab vaid DDOC vorminguid.[2]

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 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.

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

  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.

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.[11] 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[12]

  • 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.[13]

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)

Päringut esitades tuleb silmas pidada, et ühel isikul võib LDAP-is olla mitu erinevat sertifikaati (nt ID-kaart ja Digi-ID). Täpne kataloogistruktuur on nähtav SK repositooriumis.

Mobiil-ID

Isikutuvastamise ja digitaalse allkirjastamise korral on võimalik kasutada ka Mobiil-ID abi. Protsessid on samad nagu kirjeldatud vastavates peatükkides, ent allkiri räsile või nonsile antakse läbi 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 vastavale 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.[14][15]

Vajalikud DigiDocService meetodid on:[14][15]

  • MobileAuthenticate/GetMobileAuthenticateStatus - Mobiil-ID abil autentimiseks.
  • MobileCreateSignature/GetMobileCreateSignatureStatus - Loob allkirjastatud dokumendi uues sessioonis.
  • MobileSign/GetStatusInfo - Allkirjastab olemasoleva sessiooni dokumendid.
  • GetMobileCertificate - Mobiil-ID teenuse olemasolu ja sertifikaatide pärimiseks. Kuna siin ei ole vaja kasutaja sekkumist, siis see operatsioon tehakse sünkroonselt.

Mobiil-ID ülevaadet näeb eID lühitutvustuses ning kasutamise näiteid avalduste kasutusmallis. Sertifitseerimiskeskuse näiterakendused Mobiil-ID jaoks on kättesaadavad siit.

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 ehk 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):[16]

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.[17] Seega pole vaja käsitsi saata sõnumit 00 C0 00 00 YY.

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

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.[18][19]

Tehnilised märkused ja tähelepanekud

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).[20]

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).[20]

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:[21]

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

Allikaviited

  1. 1,0 1,1 1,2 http://id.ee/index.php?id=30290
  2. 2,0 2,1 http://id.ee/index.php?id=30291
  3. http://id.ee/index.php?id=30340
  4. http://www.openxades.org/dds_test_phone_numbers.html
  5. http://www.sk.ee/teenused/kehtivuskinnituse-teenus/
  6. https://www.sk.ee/teenused/kehtivuskinnituse-teenus/autentimise-ocsp/
  7. http://www.theregister.co.uk/2009/11/05/serious_ssl_bug/
  8. http://www.theregister.co.uk/2009/11/14/ssl_renegotiation_bug_exploited/
  9. http://tools.ietf.org/html/rfc5746
  10. http://id.ee/index.php?id=31039
  11. http://id.ee/index.php?id=30264
  12. https://www.sk.ee/repositoorium/ldap/
  13. https://www.sk.ee/repositoorium/ldap/ldap-kataloogi-kasutamine/
  14. 14,0 14,1 http://www.sk.ee/upload/files/DigiDocService_spec_est.pdf
  15. 15,0 15,1 http://www.sk.ee/upload/files/DigiDocService_spec_eng.pdf
  16. EstEID turvakiibi rakenduse kasutusjuhend. http://id.ee/public/EstEID_kaardi_kasutusjuhend.pdf
  17. http://docs.oracle.com/javase/7/docs/jre/api/security/smartcardio/spec/javax/smartcardio/CardChannel.html#transmit%28javax.smartcardio.CommandAPDU%29
  18. http://id.ee/public/SK-CDD-PRG-GUIDE.pdf
  19. http://id.ee/public/SK-JDD-PRG-GUIDE.pdf
  20. 20,0 20,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
  21. http://www.opensc-project.org/opensc/wiki/FrequentlyAskedQuestions#Q:IhaveasmartcardreaderinstalledbutaJavaapplicationdoesnotseeit