Uute eID rakenduste loomine

Allikas: eid.eesti.ee

Uute eID rakenduste loomine

Järgnev osa räägib uute eID rakenduste loomisest. Enne seda tasub kindlasti tutvuda ka üldteabega arendajatele.

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

Alates 2015. aastast luuakse digitaalseid allkirju BDOC vormingus. Kuni 2014. aasta lõpuni oli kasutusel DDOC formaat . Siit on näha, millised teegid, milliseid formaate toetavad. DigiDocService toetab nii BDOC kui DDOC vormingut.[7]

Allkirjastatud faili loomine

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

  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.

Kasutajatoe abi

  • Sagedane on veebilehitsejates allkirjastamise ebaõnnestumine mille peamiseks põhjuseks on veebilehitseja lisamooduli (plugina) keelatud olek. E-teenuste pakkujatel on soovitatav lisada allkirjastamise lisamooduli staatuse kontroll enne kui kasutaja alustab e-vormi täitmist. Näidisena on GitHubi (https://github.com/open-eid/hwcrypto.js/wiki/FAQ) lisatud skript mis teostab kontrolli allkirjastamise plugina kohta.

Juhul kui plugin ei ole aktiivne siis teavitada sellest kasutajat õige sõnumiga. Selliselt on võimalus tõsta teenuse kasutamiskogemust.

Veateate näidis:
Allkirjastamine ebaõnnestus!
Kontrolli kas allkirjastamise plugin on lubatud.
Juhised leiate veebist http://www.id.ee/index.php?id=36636


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

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

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

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

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

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

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

Allikaviited