ID-kaardi brauserilaienduse turvalisusest ja vahendusründest

Allkirjastamine arhitektuuriliselt jätkuvalt ebaturvaline

Riigi Infosüsteemi Amet lasi 28. jaanuaril välja uue ID-kaardi tarkvara versiooni, millega parandati veebis ID-kaardiga isikutuvastuse juures vahendusrünne. Vahendusrünne (man-in-the-middle attack) seisnes selles, et sina logid sisse ühel veebilehel, kuid telgi taga tehakse sinu nimel toimetusi ka mujal. Nädal hiljem avaldatud RIA pressiteadet on mitmed Eesti väljaanded kajastanud, kuid kahjuks ei ole see kogu lugu — turvaviga oli kergem avastada ja ulatub sügavamale kui kirjeldatud.

Nõrkus polnud selline, millele võinuks kurjategijad lihtsalt otsa komistada, vaid selle avastamiseks tuli vaeva näha ning teoreetiliseks kuritarvitamiseks oli vaja ka omada kontrolli veebilehe üle, kus saab end ID-kaardiga autentida. — Mark Erlich

Tegelikkuses ei olnud turvaviga haruldaste asjade kokkulangevus ega geniaalne mõttesähvatus, vaid on olnud arhitektuuriline viga ID-kaardi brauserilaienduses loomisest saati. Ka ei piirdu see autentimisega, vaid hõlmab ka allkirjastamist. Tehniliselt on need kaks protsessi identsed, ent hiljutise kirjavahetuse põhjal ei tundu RIA hetkel sellele tähelepanu pööravat. Võib arvata miks, kuna allkirjastamise turvavea lahendamine tähendaks kõikide täna ID-kaarti allkirjastamiseks kasutavate veebilehtede ümbertegemist. Autentimist puudutav turvaparandus aga oli kehvasti kommunikeeritud, seejuures mõistlikku alternatiivi pakkumata ja siiski sümptomi, mitte haiguse ravimine.

Mis puutub vaeva nägemisse, siis tõenäoliselt on nõrkust märganud mitmed veebiturbega vähegi kursis olevad arendajad, kes on pidanud ID-kaardi toimetusi veebilehele implementeerima. Ma ei taha hästi uskuda, et see RIAlegi üllatusena tuli, sest paari lõigu pärast märkad viga ka sina, kui detaile kuuled.

ID-kaardi toimimine

Käime alustuseks ID-kaardi tööpõhimõtted üle, et saaksid paremini aru, kuidas autentimine ja allkirjastamine toimivad ning kuidas vahendusrünne puudutab tegelikult ka allkirjastamist.

ID-kaart tugineb avaliku võtme krüptograafial (public key cryptography). Võid mõelda sellest nii, et igal ID-kaardil eksisteerib kaks unikaalset numbripaari — üks mõeldud autentimiseks, teine allkirjastamiseks. Mõlemast paarist on üks number teada vaid ID-kaardile ning teine avalikustatud. Salajase numbriga tehtud aritmeetikat saab hiljem avaliku numbriga kontrollida ja veenduda, et tulemus sai tulla vaid salajast numbrit (võtit) teadvalt ID-kaardilt. Kaardi salajasi numbreid kutsutakse vastavalt autentimisvõtmeks ja allkirjastamisvõtmeks ning avalikke numbreid avalikeks võtmeteks. Vaatamata sellele, et ID-kaart isegi omanikule salajasi numbreid (privaatvõtmeid) välja ei ütle, saame paluda tal nendega aritmeetikat teha ning tulemustega teistele tõendada, et tegu on just meie numbripaari ja seega meie ID-kaardiga.

Kuna seadusandluses on reguleeritud, mida emma-kumma võtmepaari (numbripaari) kasutamine juriidiliselt tähendab, saab öelda, et oled end kas tuvastanud või andnud millelegi allkirja. Siiski on oluline aru saada, et autentimine (mille peale kaart küsib PIN 1) ning allkirjastamine (PIN 2) on tehniliselt ja matemaatiliselt identsed.

Kui oled varem ID-kaarti kasutanud, oled tõenäoliselt pidanud arvutisse installima RIA arendatud ID-tarkvara. Peale DigiDoci rakenduse, kus saad dokumente allkirjastada, võimaldab ID-tarkvara sul ka veebis surfates ID-kaardiga sisse logida või veebis allkirju anda.

Suhtlust ID-kaardi ja veebilehitseja (nt Firefox, Chrome, Internet Explorer vm) vahel vahendab RIA arendatud pistikprogramm (plugin), mis on samasugune lisakomponent brauserile nagu ad-blockerid jm, mida oled ehk ise installinud. Veebilehe autor, kes soovib ID-kaarti toetada, lisab lehele natuke JavaScripti programmeerimiskeeles koodi, mis suhtleb RIA pistikprogrammiga, mis viimaks saadab päringu ID-kaardile. Nii saab küsida ID-kaardilt omaniku andmeid või paluda midagi allkirjastada. ID-kaardiga suhtleva lehe saab veebi paigutada igaüks, kes natukegi JavaScripti ja HTMLi oskab.

Autentimine ja vahendusrünne

Järgmiseks vaatame, kuidas ID-kaardiga sisselogimine toimib ja kus vahendusrünne avaldub. Märkad varsti isegi, et erinevalt RIA seisukohast on turvaauk üpris ilmne. Kui oled ID-kaardi tehnilise toimimise ja selle vahendusrünnetega tuttav, võid ka otse RIA lahenduse probleemini liikuda.

Sisselogimise eesmärk on tuvastada, et sinu kontrolli all on eelnevalt mainitud autentimise privaatne võti. Eeldame hetkel, et avalikku võtit, millega aritmeetika tulemust kontrollida, teab veebileht juba varasemast. Tegelikkuses tulevad siin mängu avaliku võtme infrastruktuur koos sertifitseerimisasutustega, aga need pole praegu olulised.

Protsess on üpris lihtne. Veebileht genereerib juhusliku numbri ja palub su ID-kaardil (läbi RIA arendatud pistikprogrammi) autentimisvõtmega seda kinnitada. Miks just juhusliku numbri? Sest vastasel juhul saaks autentimistulemust mujal taaskasutada. Näiteks saaks veebilehe autor su vastusega minna ise hiljem sinu eest mujale sisse logima.

Tehnilisematele inimestele, Hwcrypto.js teeki kasutades näeb koodijupp autentimisvõtme kasutamiseks välja selline:

var signature = Hwcrypto.getCertificate({filter: "AUTH"}).then(function(cert) {
  Hwcrypto.sign(cert, {value: someRandomData, type: "SHA256"}, {})
})

Selle peale küsib pistikprogramm sinult PIN 1.

ID-kaardi PIN 1 küsimise aken Chrome brauseris Windowsis.

Kui PIN 1 on õigesti sisestatud, tagastab ID-kaart läbi pistikprogrammi veebilehele matemaatilise tulemuse. Veebileht omakorda kontrollib tulemust su avaliku võtmega ja kui tulemus klapib, saab juriidiliselt öelda, et oled veebilehel end autentinud. Sest see olid ju sina, kes parasjagu sel veebilehel PIN 1 sisestas, eks? Või sai see keegi teine olla?

Mõtleme veebilehe vaatenurgast. Veebileht saab teada soovist sisse logida. Selle peale genereerib leht juhusliku numbri ja annab selle enda meelest külastaja ID-kaardile kinnitamiseks. Kui aga külastaja võtab saadud juhusliku numbri ja ise kinnitamise asemel annab edasi hoopis kellegi teise ID-kaardile kinnitamiseks? Näiteks kellelegi, kes on samal ajal tema kodulehele sisse logimas? Äkki sulle, mõne uue veebipoe külastajale. Autendid end südamerahuga, mõeldes et oled sisenemas e-poodi, samal ajal kui kulisside taga saadab e-pood sinu ID-kaardi kinnituse edasi mõnele teisele lehele, nt internetipanga lehele. Selle peale logitakse hoopis e-poe omanik sinu internetipanka, ilma et oleksid seda takistada saanud. Sellest ka "vahendusrünne" — sina ei saa omalt poolt kontrollida, kuhu tegelikult sisse logid. Probleem on üpris silmnähtav, kas pole, nüüd kus tead, kuidas autentimine töötab? See on ju sama probleem, mis puhkusereisil krediitkaardiga maksmisel — annad kaardi kelnerile, kes sellega tagaruumis peale õhtusöögi arve tasumise ka netist teleri tellib. Pole kaugeltki uut tüüpi avastus.

RIA tegi õigesti klassifitseerides selle turvaauguks. Küll aga tehti seda etteteatamata, mõistliku kasutajasõbraliku alternatiivita ja fundamentaalset probleemi lahendamata. Enne RIA lahenduse käsitlemist, vaatame korra allkirjastamist.

Allkirjastamine ja vahendusrünne

Mäletad, et rääkisime, kuidas autentimine ja allkirjastamine on matemaatiliselt identsed, sest ID-kaardil on kaks numbripaari ja need erinevad vaid juriidilise tähenduse poolest? Autentimine ja allkirjastamine on ka tehniliselt identsed. Muutsin eelnevas koodinäites vaid ühe sõna — asendasin sõna AUTH sõnaga SIGN:

var signature = Hwcrypto.getCertificate({filter: "SIGN"}).then(function(cert) {
  Hwcrypto.sign(cert, {value: signableHash, type: "SHA256"}, {})
})

Selle peale küsitakse sinult PIN 1 asemel PIN 2.

ID-kaardi PIN 2 küsimise aken Chrome brauseris Windowsis.

Tulemus on juriidiliselt võrdne omakäelise allkirjaga. Kuna tehnilised protsessid on võrdsed, võime järeldada, et mis iganes turvavead on autentimisel, puudutavad need ka digiallkirjastamist. Kujuta näiteks ette sama e-poodi, millest just autentimise kontekstis rääkisime. Näiteks võib e-pood sinult paluda järelmaksulepingu allkirjastamist, telgi taga aga sinu eest su allkirjaga kuskil hoopis hääletada. Nagu PIN 2 pildilt ülal näed, ei saa sina kuidagi enne allkirja andmist veenduda, mida päriselt allkirjastad. Kaasav demokraatia on üpris populaarseks muutunud. Miks ei võiks pangad näiteks ülekannet kinnitades su allkirja salaja hoopis mõnda e-demokraatia platvormi suunata? Äkki mõne sellise algatuse toetuseks, mis neile ka kasulik oleks. Ja sina ei saaks sellest kunagi teada, et isegi allkirja tühistama minna.

Üks RIA osakonnajuhataja andis mõista, et allkirjastamise vahendusrünne pole oluline seepärast, et iga allkirjastamist võimaldav e-teenus saab ju niikuinii allkirjastatava dokumendi viimasel hetkel millegi muu vastu välja vahetada. Tõepoolest. Aga kui ID-kaardi kasutamise turvalisus peakski seisnema veebisaitide usaldamises, siis poleks olnud vaja ka autentimise vahendusründest probleemi teha. Paneme silmad kinni ja loodame parimat.

Lahenduse probleem

Fundamentaalne probleem nii autentimise kui ka allkirjastamisega seisneb selles, et sina kui ID-kaardi omanik ja veebikülastaja ei tea, mida ID-kaardiga kinnitad. Nagu ülal kirjeldasin, nii autentimise kui ka digiallkirjastamise puhul jõuab su ID-kaardini vaid üks veebilehe antud number, kuid numbri allikat ja sihtkohta sa teada ei saa. Seega pole võimalik öelda, kas kinnitamiseks saadetud numbrit kasutatakse heaotstarbeliselt või hoopis sinu eest salaja mujal sisselogimiseks või allkirjastamiseks. See on nagu lepingule alla kirjutamine, ilma et sa seda enne lugeda saaks.

Mida siis RIA vahendusründe takistamiseks tegi? Keelas pistikprogrammi abil ainult ID-kaardiga autentimise. Tehniliselt öeldes keelas RIA AUTH parameetri kasutamise ehk veebilehe ligipääsu autentimisvõtmele. Allkirjastamise vahendusründest pole aga kusagil juttu. Pistikprogrammi koodimuudatus tehti juba 16. detsembril 2020, kuid avalikustati alles 28. jaanuaril GitHubis. Pressiteade avaldati alles nädal hiljem. Muudatus lõhkus seega üleöö mitmetel saitidel ID-kaardiga autentimise, sest aastavahetusel anti teada vaid RIA väljavalitutele. Mitmel neist saitidest ei ole tänaseni ID-kaardiga autentimiseks head alternatiivi, sest ainus teine meetod, brauseritele sisseehitatud serdiautentimine (TLS client certificate authentication), on tunduvalt kehvema kasutajakogemusega ning paljud serveripakkujadtls-auth seda ei toeta. Parema kasutajakogemuse ja võimaluste pärast pistikprogrammiga autentimine leviski. Nagu Swedbankki tunnistas, oli see kasutaja vaatenurgast töökindlam. Allkirjastamise kõrval ei olnud autentimine ohtlikum, sest mõlemad on auklikud.

Tehti õigesti, et probleemiga tegeleti, kuid seda oleks pidanud lahendama teisiti. Esiteks ei olnud turvaprobleem "peidus" ega vajanud avastamiseks vaeva. Selliste märgatavate vigade pea kaks kuud salajas hoidmine teeb rohkem kahju kui head, sest kõik need, kes on soovinud seda ära kasutada, olid sellest kahtlemata juba aastaid teadlikud. Ainult tavalised veebikasutajad ja veebilehtede omanikud said sellest liiga hilja teada, et end kaitsta.

Teiseks kulus pea kaks kuud sümptomi eemaldamiseks, mitte fundamentaalse probleemi lahendamiseks. Olgu, ilmselt parandati sümptomit ehk tunnike, kuid selle avaldamisega viivitati veebruarini. Ja sedagi kirjeldati vaid napisõnaliselt autentimist mainides, olgugi et probleem puudutab ka allkirjastamist. Kahe kuu jooksul oleks saanud autentimise turvaprobleemi lahendada ka ilma selle eemaldamiseta. Eriti kuna niikuinii tuli veebilehtedel muudatusi teha.

Probleemist ja potentsiaalsetest lahendustest oleks pidanud RIA juba detsembris arendajatele avalikult teada andma. Nõnda oleksid saanud veebiarendajad anda tagasisidet ja ühiselt parema lahenduseni jõuda. Üksikute saitide turvaprobleeme võib suletud uste taga lahendada, ent mis puutub me kõikide ID-kaartide turvalisusesse, siis protsessi läbipaistvus on olulisem. Alustuseks, RIA ei tea kõiki turvaprobleemidest või muudatustest mõjutatud osapooli, sest ID-kaardi toe lisamiseks pole vaja veebilehte kuskil registreerida. Kuid veelgi tähtsam on läbipaistvus seepärast, et allkirjastamise vahendusründest me nii kergelt lahti ei saa. Kas või puhtalt seepärast, et see tähendab kõikide täna allkirjastamist toetavate saitide ümbertegemist. Isegi kui tehnilise lahenduse saaks nädalaga välja mõeldud, ei saa sarnaselt autentimisele päevapealt allkirjastamist lõhkuda.

Probleemi lahendamine

Mida siis ette võtta? Kõigepealt leian, et on oluline inimesi informeerida netis autentimise ja allkirjastamise riskidest. Riskid puudutavad tegelikult ka Mobiil-ID ja Smart-ID kasutajaid, kuid sellest räägime teinekord. Nii kaua, kui ID-kaardi pistikprogramm ei kuva konkreetselt, kus autendid või mida allkirjastad, tasub olla ettevaatlik. Miski ei garanteeri, et telgi taga ei toimu vahendusrünnet ja tõenäoliselt jääb see nii veel pikka aega.

Lohutuseks võin öelda, et brauseritele sisseehitatud sertifikaadiga autentimine, mida RIA autentimiseks kasutada soovitab ja mille kehva kasutajakogemust mainisin, näitab korra saidi aadressi (pildil test-eid.eesti.ee). See annab mõista, kuhu sisse logid.

ID-kaardi sertifikaadi valimise aken brauseritele sisseehitatud autentimiseks.

Saiti mainitakse küll vaid sertifikaati valides ja mitte hiljem PIN 1 sisestades, nii et eriti selgeks lahenduseks seda kutsuda ei saa. Õnneks on tehniliselt selline autentimine vahendusründe eest kaitstud, kuid meetod pole kaugeltki töökindel ega kasutajasõbralik. Kirjutan sellest tulevikus, et saaksid ka ise naerda või nutta.

RIAl tuleks oma lähenemine antud probleemi lahendamisel kriitiliselt üle vaadata. Kui nad ei teadnud, miks veebilehed pistikprogrammiga autentimist teostasid, tasub välja selgitada, mitte naljatada, et Põhimõtteliselt avastati, et taignarulliga saab ka naelu seina lüüa. Kasutajakogemus ning töökindlus on veebis päris olulised ning sellest tulenevalt on vahel väikese riskiga lahenduste kasutamine teadlik valik. Mõne süsteemi turvalisus sõltub jällegi tema nõrgimast lülist. Kuna allkirjastamine on jätkuvalt ebaturvaline, ei pruugi abi olla ka autentimise kaitsmisest.

Irooniliselt pole RIA enda juhendid aastaid vahendusründele õieti tähelepanu pööranud. Sellest tulenevalt võib kahtlustada, et lehti, kuhu saab vahendusründega sinu nimel sisse logida, on sadu. Olukorras, kus autentimise arendamine on niivõrd veaohtlik, tuleks RIAl võtta vastutus terviksüsteemi eest, mitte näidata näpuga vaid veebilehtede suunas. Suhtumine, mis seab kogu vastutuse veebilehele, ei ole jätkusuutlik ega praktikas turvaline. Sinu ID-kaardi ja digiidentiteedi kasutamise turvalisus ei tohi tugineda sellel, et kõik teised veebilehed, k.a teistes riikides, toimivad 100% turvaliselt ja on 100% usaldusväärsed. Seda ei juhtu kunagi. Sinul peaks olema võimalus autentides ja allkirjastades kindel olla, kuhu või millele sinu kinnitus lõpuks läheb.

Sellise turvalise tehnilise lahenduse väljatöötamine peaks toimuma avalikkuse silme ees, nii et iga asjast huvitatu saab protsessi jälgida, vajadusel kaasa rääkida ning probleeme varakult välja tuua. ID-kaardi turvaline ja töökindel toimimine on täna hindamatu nii eraelus, äris kui ka demokraatias. Samade suletud uste taga jõuame sama tulemuseni.


Kui sul on artikli sisu kohta küsimusi, võid kirjutada andri@dot.ee.


  1. Levinud rakenduste majutusplatvormid nagu Heroku jt ei toeta sertifikaatidega autentimist.