Üldteavet arendajatele

Allikas: eid.eesti.ee

Üldteavet arendajatele

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

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

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

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

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

BDOC

BDOC on uus digitaalallkirja vorming, mis asendas 2015. aastal Eesti-spetsiifilise DDOC digitaalallkirja vormingu.

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

Uuest BDOC digiallkirjaformaadist on olemas kaks alamformaati, mis on tehniliselt erinevad. Selleks, et tavakasutaja suudaks neid paremini eristada kasutatakse nende puhul erinenevaid faili laiendeid - .bdoc ja .asice. Nende tehniline erinevus on kirjeldatud allpool.

Enamus Eesti asutusi ja e-teenuseid on üle läinud juba BDOC formaadile, ent võib juhtuda, et nende infosüsteem suudab esialgu vastu võtta .bdoc laiendiga dokumente. Rahvusvaheliselt aga tunnustatakse eelkõige formaati, mille laiendiks on .asice.

  • .bdoc ehk BDOC-TM ehk ASiC-E LT-TM allkiri on BDOC allkiri ajamärgendiga - allkirja pikaajaline tõestusväärtus on tagatud kasutades RFC 2560 standardil põhinevat ajamärgendit (time-mark). See on Eestis vaikimisi kasutusel olev allkirjaformaat alates 2015. aastast, tegemist on Eesti-spetsiifilise formaadiga.
  • .asice ehk BDOC-TS ehk ASiC-E LT allkiri on BDOC allkiri ajatempliga - erinevalt LT-TM formaadist on allkirja pikaajaline tõestusväärtus tagatud RFC 3161 standardil põhineva ajatempliga (time-stamp). ASiC-E LT allkiri on parima rahvusvahelise ühilduvusega.

Täpsemat tehnilist infot hetkel kasutuses oleva BDOC-vormingu kohta saab lugeda Eesti standardidokumendist EVS 821:2014.

BDOC formaadi kasutuselevõtmisel tuleks erinevate profiilide valimisel lähtuda allkirjastatud dokumentide kasutuse eesmärgist ja eeldatavast kasutajaskonnast. Parima rahvusvahelise ühilduvuse jaoks tuleks allkirjade loomisel kasutada ajatempliga profiili, valideerimisel on soovitatav toetada mõlemat profiili. Tuleks arvestada ka, et juba allkirjastatud dokumendile tuleb allkiri lisada olemasoleva allkirjaga samas formaadis.

BDOC vormingus dokumentide pikaajalise säilivuse tagamiseks on tulevikus võimalik kasutada arhivaalset ajatembeldamist. See mehhanism rajaneb põhimõttel “kindlustame seda, mis võib olla nõrk”. Järjestikku ajatemplid kaitsevad kogu materjali nõrkade räsialgoritmide ning krüptograafilise materjali ja algoritmide murdmise eest. Arhivaalse ajatempliga BDOCi on võimalik valideerida libdigidocpp teegis (vt juhis http://open-eid.github.io/libdigidocpp/manual.html peatükk Opening document, validating signatures and extracting data files)

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 või ka infosüsteemides eID funktsionaalsuse kasutamiseks on loodud erinevad teegid, soovitame kasutada infot lehelt http://id.ee/?id=30290. Sealt leiab teekide toeperioodi pikkuse, samuti toetatud digiallkirjastamise vormingute info.

Uute arenduste puhul tuleks kasutada eeskätt uusimat C++ teeki libdigidocpp või Java teeki digidoc4j. Seejuures on tõenäoliselt kõige mugavam kasutada teegiga kaasatulevat käsurea-utiliiti, mille kasutamisjuhised leiab teegi dokumentatsioonist (vt http://open-eid.github.io/digidoc4j/ peatükk Utility program overview ja http://open-eid.github.io/libdigidocpp/manual.html#utility peatükk Libdigidocpp utility program).

digidoc4j

Uus Java teek, mis on mõeldud asendama jdigidoc teeki.

libdigidocpp

Antud teek on mõeldud asendama libdigidoc teeki.

Versioonis 3.12 (avalikustamine 2016. a I kvartal) on planeeritud API muudatused, mille kohta leiab lisainfot https://github.com/open-eid/libdigidocpp/wiki/API-changes-(v3.12).

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 BDOC ja DDOC allkirjastamise formaati.

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

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

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

Testteenus

Testimiseks ja arendamiseks on olemas ka tasuta testkeskkond

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

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

Isikuandmete faili kasutamine veebis

Uue Digidoc-pluginaga pole võimalik lugeda ID-kaardilt isikuandmete faili. Ainus võimalus isikuandmete faili lugemiseks on kasutada eidenv rakendust, mida levitatakse OpenSC pakiga.

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.

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/etoken/SAC_9.0/SAC_9_0_43_Windows.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).[10]

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

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

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