Sertifikaciono telo Privredne komore Srbije je 23. decembra u 8:53 ujutro opozvalo sertifikat koji prateći program za pristup CROSO portalu (SecurityTray) koristi za komunikaciju između čitača kartice i portala.

Čim računar „dohvati“ novu listu opozvanih sertifikata sprečava se dalji pristup i korisnicima se prikazuje poruka „korisnik prekinuo komunikaciju sa uređajem…“.

Istovremeno najavljene su izmene na portalu zbog kojih pristup neće raditi od 30.12. ove godine do 09.01. naredne godine. Ne bih da zamaram tehničkim pisanjem, ali rešenje koje autori (Saga doo) koriste za vezu browsera i čitača kartice nije adekvatno, PKS CA je u startu izdalo pogrešan sertifikat koji se ne koristi na odgovarajući način, ali takođe smatram da je reagovanje PKS CA u ovom trenutku brzopleto. Ovim je ugroženo funkcionisanje važnog servisa za veliki broj korisnika.

Izvod iz CRL-a (lista opozvanih sertifikata) pokazuje vreme i razlog opoziva:

Serial Number: 1A9C88C71CF9580B
Revocation Date: Dec 23 07:53:51 2016 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
   Key Compromise

Kako da pristupite portalu?

Ukoliko za pristup CROSO portalu koristite Google Chrome ili Internet Explorer i pri pokušaju prijave na portal dobijate poruku „korisnik prekinuo komunikaciju sa uređajem…“ iako je do 23. decembra sve radilo, potrebno je da ručno u pregledaču otvorite lokalni sajt https://localhost:9876 SecurityTray aplikacije i dodate bezbednosni izuzetak za pristup kako bi sve ponovo proradilo.

Mozilla Firefox

Firefox ovim nije pogođen jer ne radi proveru opozvanosti sertifikata putem CRL-a.¹⁾

Možete da koristite Mozilla Firefox za pristup portalu. Ako niste ranije koristili Firefox neophodno je da instalirate sertifikate PKS CA prema uputstvu sa CROSO sajta.

Internet Explorer

Kada otvorite https://localhost:9876 greška se prikazuje kao na slici ispod gde kao razlog greške vidimo opozvani sertifikat (engl. certificate has been revoked):

U tom slučaju, potrebno je da otvorite Internet Options, a zatim na kartici Advanced u grupi Security isključite opciju „Check for server certificate revocation*“.

Ovo je inače loša ideja (ali trenutno neophodna) pošto Internet Explorer sada za svaki sajt koji posećujete neće proveravati da li je on možda kompromitovan. U RETKOM slučaju ovo bi moglo da ugrozi vašu bezbednost pri korišćenju interneta.

Nakon promene postavki, navedeni sajt će se prikazati kao na slici ispod, što je potvrda da ste uspešno dodali izuzetak.

Možete da zatvorite prozor i nastavite rad. Ne zaboravite da nakon objavljivanja nove verzije programa za pristup portalu ponovo uključite opciju koju ste isključili kako bi vratili bezbednost na odgovarjući nivo.

Google Chrome

Kada otvorite https://localhost:9876 greška se prikazuje kao na slici:

Da dodate izuzetak kliknite bilo gde na sivi prostor i „na slepo“ ukucajte reč badidea

Pritiskajte slovo po slovo na tastaturi (b, a,…) iako se ništa neće dešavati i zatim pritisnite taster Enter na tastaturi.

Upozorenje će nestati i prikazaće se ekran kao na slici ispod sa crnim tekstom HTTP ERROR 404 što je potvrda da ste uspešno dodali izuzetak. Dok ovo radite ne prozivajte mene, ja samo delim savet i niti sam pravio niti sam savetovao one koji su pravili ovaj program i ovakvo rešenje.

Tehnički komentar

Opoziv kao razlog navodi „kompromitaciju ključa“ što zvuči dosta loše.

U pitanju je međutim sertifikat za lokalni server (CN=localhost) koji „obezbeđuje“ programče SecurityTray. Sertifikat i privatni ključ se nalaze u instalaciji programa koja se preuzima sa sajta portala. Privatni ključ mora da bude dostupan programčetu, što znači i da mora da bude podeljen svim korisnicima. Tu tehnički govorimo o „kompromitaciji“ (ključ je javno dostupan) iako je rešenjem to tako od početka zamišljeno.

PKS CA nikada nije trebalo ni da izdaje (potpisuje) ovakav sertifikat, a SAGA doo nije trebalo da osmisli rešenje koje zahteva da se privatni ključ deli svim korisnicima bez jasnije komunikacije sa PKS CA o uslovima pod kojima će se ključ koristiti. Jer da je bilo potpunog razumevanja između dve strane ne bi sada imali opoziv. Ali kada je sve već tako zamišljeno od početka korišćenja SecurityTray aplikacije, ne vidim čemu brzopletost opoziva bez spremnog alternativnog rešenja i obaveštavanja korisnika portala.

Rešenje je moglo da ima samopotpisani sertifikat koji će tokom instalacije biti dodat kao izuzetak u Mozilla Firefox, odnosno odgovarajući Windows Cerificate Store za Google Chrome i Internet Explorer. Za takav sertifikat nije potrenno da isti izdaje sertifikaciono telo, koje bi time eventualno kršilo sopstvenu politiku izdavanja i došlo u situaciju da isti opoziva.

Ostaje da vidimo kako će problem biti rešen sa najavljenim izmenama portala početkom januara.

¹⁾ Firefox kao i sertifikati na većini sajtova koristi drugi moderniji mehanizam za proveru pod nazivom OCSP, što PKS CA ne podržava, pa Firefox neće ni znati da je sertifikat opozvan. ↑

Nakon što je CROSO portal bio nedostupan deset dana radi pripreme nove verzije aplikacije, u ponedeljak 9. januara objavljena je nova verzija SecurityTray aplikacije koja je u sebi sadržala ozbiljan i nedopustiv bezbednosni propust.

SecurityTray aplikacija služi da uspostavi komunikaciju između sajta portala i čitača pametnih kartica, i na taj način predstavlja alternativu za ranije korišćene Java aplete ili Native Messaging ekstenzije.

Sadržaj

1. SecurityTray aplikacija
2. Ukratko o SSL sertifikatima
3. CROSO pre 30. 12. 2016.
4. CROSO 9. januara 2017.
5. Zaključak o servisima e-uprave
6. Najnoviji CROSO SecurityTray

SecurityTray aplikacija

Aplikacija prvo pokreće lokalni veb servis na računaru korisnika (localhost), a zatim koristeći HTTP CORS mehanizam uspostavlja komunikaciju između sajta i aplikacije preko HTTP API-ja. Na taj način sajt može da zatraži od lokalne aplikacije da koristeći midlver i karticu u čitaču izvede operaciju elektronskog potpisivanja.

Kada se veb sajtu pristupa preko HTTPS protokola (zeleni katanac, zaštićena i šifrovana komunikacija), HTTP CORS mehanizam zahteva da i lokalni veb servis bude obezbeđen na isti način. I tu nastaje problem, koji ne postoji u slučaju kada se koriste druga pomenuta rešenja.

Svaki HTTPS sajt ili servis, pa i ovaj lokalni koji obezbeđuje SecurityTray aplikacija, zahteva dve stvari (1) par ključeva (tajni i javni), gde se tajni ključ čuva poverljivo i koristi u formiranju zaštićenog kanala i (2) SSL sertifikat u koji se ugrađuje javni ključ i kojim se dokazuje identitet sajta, odnosno veb servisa.

Oba ova dela moraju da budu dostupni instaliranoj SecurityTray aplikaciji, bilo da se generišu pri prvom pokretanju ili da su pripremljeni unapred i uključeni u instalaciju aplikacije.

Ukratko o SSL sertifikatima

SSL sertifikat poseduje dva polja kojima se dokazuje identitet sajta. Subjekat sertifikata (Subject, npr. google.com) i izdavalac sertifikata (Issuer). Izdavalac je najčešće neko telo od poverenja (engl. Certificate Authority) koje nakon što utvrdi da je upravo na primer Google vlasnik određenog para ključeva izdaje sertifikat. Izdati sertifikatu navodi google.com kao ime subjekta i sadrži javni ključ iz pomenutog para.

Pri povezivanju na google.com, veb pregledač dobija kopiju ovog SSL sertifikata i potom po standardima definisanoj proceduri proverava da li je izdavalac poznat i pouzdan, da li je subjekat sertifikata upravo google.com i da li izdavalac sertifikata nije u međuvremenu opozvao sertifikat. Ukoliko je provera uspešna, znamo da je Google vlasnik para ključeva i pregledač može da formira zaštićeni kanal.

Izdavalac može da bude i posrednik, tj. da ima svog izdavaoca, pa pri proveri SSL sertifikata uvek govorimo o proveri lanca sertifikata, gde u vrhu (engl. root) treba da stoji poznat i pouzdan sertifikat, a svaki sertifikat iz lanca je validan u odnosu na prethodni. Krajnji sertifikati (bez CA oznake) ne mogu da budu izdavaoci, tj. ne mogu da grade dalji lanac. SSL sertifikati su po pravilu krajnji sertifikati.

Sertifikat se smatra pouzdanim ukoliko se nalazi u tzv. Trusted Root skladištu. Veb pregledači Internet Explorer i Google Chrome na Microsoft Windows operativnom sistemu koriste Windowsovo Trusted Root skladište, dok pregledač Mozilla Firefox koristi svoje skladište. Drugi sistemi i programi imaju sopstvena skladišta.

Uloga izdavaoca sertifikata je da postanu deo ovih skladišta, ili da na neki drugi način postanu subjekti od poverenja (npr. postanu ovlašćeni od strane države), i da zatim utvrđuju identitet subjekata, izdaju im sertifikate i u slučaju incidenata iste opozivaju, najčešće sve uz novčanu nadoknadu.

Pored sertifikata koje ugrađuje proizvođač, korisnik i administrator računara ili mreže mogu da dodaju i dodatne sertifikate u ova skladišta. Na primer sertifikati domaćih sertifikacionih tela najčešće nisu uključeni u pomenuta skladišta.

Kada su u Trusted Root skladištu samo pouzdani izdavaoci sertifikata korisnik koji poseti google.com, sajt državne uprave ili sajt svoje banke i u uglu vidi zeleni katanac kao obaveštenje da je konekcija bezbedna, odnosno ne dobije nikakvo sigurnosno upozorenje, može biti siguran da se povezao upravo na ovaj sajt i da napadači ne mogu da presretnu lozinke, podatke, naprave lažne transakcije i slično.

Ako se u Trusted Root skladištu nalazi i neki nepouzdan izdavalac, gde napadač iako na primer nije Google može da dobije google.com sertifikat, taj napadač bi mogao da presretne komunikaciju (npr. postavljanjem wi-fi mreže), podmetne ovaj lažni sertifikat i zatim presretne lozinke i podatke, preuzme identitet korisnika i na razne druge načine ugrozi bezbednost korisnika.

HTTPS je u osnovi bezbednog veba i interneta, aktivno se koristi od 2000-ih godina. Kako su otkrivani novi napadi i kako je uopšte rasla potreba korisnika da bezbedno koriste sve značajnije servise, u poslednjih 15 godina više puta su inovirane preporuke, protkoli i standardi, a veb pregledači su postali sve striktniji u proveri validnosti SSL sertifikata.

CROSO pre 30. 12. 2016.

U ranijoj verziji pre 30. decembra 2016. godine SecurityTray aplikacija je koristila SSL sertifikat čiji je izdavalac Sertifikaciono telo Privredne komore Srbije. Subjekat sertifikata je localhost (lokalni veb servis koji pokreće SecurityTray aplikacija). Privatni ključ koji odgovara ovom sertifikatu, što je bilo neophodno za ovo tehničko rešenje, je bio uključen u instalaciju aplikacije.

PKS CA je jedno od nekoliko sertifikacionih tela koja su ovlašćena da izdaju kvalifikovane elektronske sertifikate za elektronski potpis. U pitanju je vrsta elektronskog identiteta. Zakonom o elektronskom potpisu i podzakonskim aktima propisani su posebni uslovi koje ovi izdavaoci moraju da ispunjavaju, počev od dokumentovanja politike izdavanja i postupaka rada, posebnih kadrovskih resursa, posedovanje opreme, pa do nadzora nadležnog ministarstva.

Kvalifikovane sertifikate PKS CA izdaje u skladu sa objavljenom politikom kroz lanac izdavaoca:

PKS CA Root
  PKS CA Class1 - Kvalifikovani sertifikati
    izdati kvalifikovani sertifikati...

Istovremeno PKS CA izdaje SSL sertifikate kroz drugi lanac izdavaoca sa istim korenskim sertifikatom:

PKS CA Root
  PKS CA Class2 - IT resursi
    izdati drugi sertifikati

PKS CA ne objavljuje politiku izdavanja nekvalifikovanih sertifikata, ali bi po stručnoj praksi trebalo da je ima.

Važeći podzakonski pravilnik nije sasvim jasan u vezi sa tim da li je dozvoljeno iz iste PKI hijerarhije (PKS CA Root) formirati podređena CA koja izdaju kvalifikovane i nekvalifikovane sertifikate, ali recimo da bi doslovna primena spornog člana bila nemoguća, a da postoji i sertifikaciono telo koje različite vrste sertifikata izdaje istim sertifikatom.

Uobičajna upotreba SSL sertifikata je da subjekat sertifikata čuva privatni ključ u tajnosti. Politike sertifikacionih tela takođe najčešće predviđaju da ukoliko dođe do kompromitacije privatnog ključa odgovarajući sertifikat odmah bude opozvan.

Privatni ključ localhost sertifikata koji se koristi u SecurityTray aplikaciji je bio uključen u javno objavljenu instalaciju aplikacije od samog početka, ali moguće da je PKS CA toga postalo svesno tek 23. decembra ujutro kada je sertifikat opozvan navodeći upravo kompromitaciju ključa.

Slažem se sa komentarima koji su se mogli čuti tada da PKS CA kao jedan od ovlašćenih izdavalaca kvalifikovanih elektronskih sertifikata ima previše važnu ulogu i da izdavanje ovakvog sertifikata (nepoznati subjekat, javno dostupan privatni ključ) čak i da je u skladu sa politikom PKS CA može da omogući neočekivane zloupotrebe. Sa te strane reakcija PKS CA je odgovarajuća. Činjenica da je takav sertifikat ipak bio izdat, a onda opozvan, pokazuje kako je nešto svakako zaškripalo u komunikaciji. Kako bilo, tog petka korisnici koji su koristili Internet Explorer ili Google Chrome su se suočili sa time da ne mogu više da pristupe CROSO portalu.

Sedam dana kasnije pristup portalu je ograničen radi najavljenih izmena.

CROSO 9. januara 2017.

Nakon deset dana pauze, objavljena je nova verzija SecurityTray aplikacije koja više nije koristila sertifikat PKS CA, već nešto mnogo gore.

Aplikacija je bez znanja korisnika u Trusted Root skladište dodavala svoj CA sertifikat koji može da izdaje druge sertifikate, menjajući ono što je do tada za njih radilo PKS CA. Privatni ključ ovog CA sertifikata je bez ikakve potrebe bio takođe uključen u instalaciju.

Napadač je mogao da iskoristi javno dostupan privatni ključ i da napravi bilo koji lažni SSL sertifikat.

Na računarima svih korisnika koji bi instalirali SecurityTray aplikaciju bi takav lažni sertifikat bio označen kao pouzdan, što bi napadač mogao da iskoristi da ukrade lozinke, podatke ili preuzme identitet korisnika pri korišćenju servisa na internetu, e-bankarstvu, e-upravi i slično.

Problem bi postojao i u slučaju da privatni ključ CA sertifikata nije bio uključen u instalaciju, ali je ovim svakako postao očigledniji. Fomiranje sertifikacionog tela, naročito kada se taj novi sertifikat dodaje u Trusted Root velikog broja korisnika zahteva posebne mere bezbednosti u vezi za celokupnim životnim ciklusom tajnog ključa i visok stepen profesionalne odgovornosti. Sve i da privatni ključ nije bio očigledno javno objavljen, korisnici ne mogu da znaju kako je ključ nastao, gde je sve završila njegova kopija i ko bi mogao da ga zloupotrebi. To što je ključ objavljen, na neki način je ispala srećna okolnost jer je izazvalo brzu i efikasnu reakciju.

Prijavu incidenta poslao sam nešto pre 15 časova na više adresa, uključujući MTT, RATEL, kao i na kontakt adrese autora softvera do kojih sam uspeo da dođem.

Sutradan 10. januara nešto posle 13 časova isključen je pristup CROSO portalu, a već 11. januara pojavila se nova verzija SecurityTray aplikacije. Želeo bih da zahvalim Savi Saviću ispred Ministarstva za razumevanje ozbiljnosti situacije i angažovanje da se u saradnji sa zaposlenima u CROSO-u i dobavljačima aplikacije problem brzo otkloni.

Nova verzija SecurityTray aplikacije koristi samopotpisani krajnji sertifikat, bez dodavanja sertifikata u Trusted Root čime se sprečava mogućnost da ga napadač iskoristi za izdavanje drugih sertifikata.

Kako sertifikat nema izdavaoca, mora se definisati sigurnosni izuzetak kako bi se ovaj sertifikat bez izdavaoca označio kao pouzdan. Internet Explorer dozvoljava CORS mehanizam i kada localhost sertifikat nije validan, pa nije potrebna dalja aktivnost korisnika, a uputstvo za korisnike pregledača Google Chrome i Mozilla Firefox objašnjava kako je moguće ručno dodati izuzetak.

Instalacija nove verzije uklanja CA sertifikat iz Windowsovog Trusted Root skladišta koji je bio dodat prethodnom instalacijom. Za korisnike Mozilla Firefox pregledača koji su ovaj sertifikat ručno dodali po uputstvu su upućeni kako da sada isti ručno obrišu kako bi povratili bezbednost u korišćenju interneta.

Zaključak o servisima e-uprave

Ne bih dodatno komentarisao kako ovakav propust uopšte može da se dogodi i zašto kritični servisi e-uprave ne prolaze kroz dodatne provere pre nego što se neadekvatna rešenja objave korisnicima. Činjenica da servis može da bude nedostupan 10 dana radi izmena, ukazuje i na nepostojeći ili loše zamišljeni plan kontinuiteta.

Na ozbiljan propust sam morao da ukažem i početkom 2014. godine kada je portalu ePorezi Poreske uprave moglo da se pristupi bez ikakve autentikacije, zaobilazeći očitavanje podataka sa pametne kartice, prostim unošenjem JMBG osobe u čije ime se pristupa. I pored direktnog sastanka u PU za rešavanje tog problema tada bilo je trebalo znatno duže vremena koje se ne meri danima već, neverovatno, mesecima.

Osim neozbiljnosti u implementaciji važnih servisa i nedovoljne kadrovske posvećenosti, uočljiv je još jedan problem. IT se često menja, objavljuju se nove verzije softvera, ispravljaju se do tada nepoznati propusti i menja preporučena praksa. Određeno rešenje e-uprave namenjeno opštoj javnosti i korisnicima koji imaju svoje računare, koje koriste na različite načine ne može da se uvede i zaboravi, već mora da se ažurira, menja i prilagođava novim okolnostima.

Situacije u kojima prolaze godine pre nego što se rešenje prilagodi na novu verziju Jave, pa korisnici moraju da ukidaju bezbednosne zaštite i ugrožavaju svoj računar i podatke, ili gde neke aplikacije e-uprave ne podržavaju Windows 10 ni dve i po godine nakon njegovog objavljivanja prosto nisu dopustive.

Stoji i opaska kako skoro svi uvedeni servisi zahtevaju računar i Windows operativni sistem. Kao da korisnici drugih platformi nemaju pravo na e-upravu. Podrška za m-government se najavljuje kao nešto potpuno novo. Nadam se da je to šansa da upravo postojeća veb rešenja budu zamišljena tako da rade na svim platformama i operativnim sistemima, a ne kao alternativa zasnovana na SMS-u i USSD kodovima.

Ne mogu da se ne setim i situacije sa uslugom zamene saobraćajne dozvole na portalu eUprava, koja mi je posebno bliska jer je dobavljač iskoristio moje open-source rešenje za čitanje lične karte. Nakon toga u avgustu 2014. godine MUP je počeo da izdaje nove lične karte, a već u septembru sam objavio novu verziju open-source koda. Rešenje na portalu eUprava nije ažurirano sve do polovine 2015. godine, čime je svima sa novim ličnim kartama onemogućena zamena saobraćajne preko portala. Čak i tada Java aplet nije ispravno potpisan, pa je za učitavanje i korišćenje usluge potrebno posebno podešavanje računara i isključivanje bezbednosnih postavki.

Najnoviji CROSO SecurityTray

Poslednje tehničko rešenje SecurityTray aplikacije je primereno svrsi i ne ugrožava bezbednost korisnika, ali je korisnički doživljaj pri korišćenju mogao da bude bolji.

Najpre, instalaciona procedura je mogla samopotpisani localhost sertifikat da doda u Windowsova skladišta Trusted People i Other People. Trusted People je dokumentovano skladište za dodavanje izuzetka za samopotpisane sertifikate koji inače ne učestvuju u proveri i formiranju lanca.

Trusted People Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook

U ovom slučaju korisnici ne bi morali da isključuju postavke u Google Chrome pregledaču, a smanjuje se rizik da neka nadogradnja Windowsa ili Internet Explorera 11 spreči komunikaciju između lokalnog servisa i veb sajta u ovom pregledaču.

Za Mozilla Firefox, preporučeno rešenje za programersko dodavanje izuzetka jeste ubacivanje sertifikata u Servers listu NSS skladišta (kako bi sertifikat bio dostupan) i upisivanje njegovog otiska u datoteku cert_override.txt unutar korisničkog profila. Takođe, kada bi instalacija ovo radila automatski, izbegava se potreba za ručnom intervencijom korisnika.

Zadovoljstvo korisnika bi bilo bolje i ako bi programeri u lokalni HTTPS server i njegov HTTP API dodali / rutu sa nekom razumnom porukom, tipa „Instalacija SecurityTray aplikacije je uspešna“ uz eventualnu mogućnost dijagnostike komunikacije sa čitačem. Korisnici bi tako mogli da provere instalaciju aplikacije, te da li podešavanja eventualnog lokalnog firewalla ili antivirusa ometaju njen rad. Trenutno rešenje predviđa da se korisnicima ili prikazuje greška HTTP 404 kao potvrda da aplikacija radi (!) ili pun ekran đubreta koje se ispisuje kada se pristupi /getTicket stranici lokalnog servisa.

Zapakovao sam jednostavno programče koje omogućava uklanjanje (brisanje) e-potpisa iz PDF dokumenta.

Program može biti koristan u situaciji ukoliko je pri potpisivanju dokumenta uključena opcija „Lock Document After Signing“ uz koju Adobe Reader DC neće dozvoliti dodavanje novog potpisa. Upotrebom programčeta možete da uklonite e-potpise iz PDF dokumenta i da ga zatim ponovo potpišete.

Ukoliko je dokument potpisan vidljivim potpisom, sličica će ostati u vidljiva ali više neće imati pridruženi e-potpis u Signature Panelu. Program u verziji za Microsoft Windows možete da preuzmete ispod.

unsignpdf(2017-01-26)

A simple tool to easily remove all PDF digital signatures from the Signature Panel

Za GNU/Linux i druge operativne sisteme, dostupan je Java jar paket unsignpdf.jar.

Program se pokreće bez instalacije, ali zahteva da na računaru imate instaliranu Javu. Upotreba je jednostavna. Po pokretanju odaberite PDF dokument i zatim unesite ime kako želite da sačuvate dokument bez potpisa.

Ovaj program zapravo koristi gotov primer FlattenSignature.java iz dokumentacijeiText projekta, popularne Java biblioteke za rad sa PDF dokumentima.

Sličan rezultat se može postići i „štampanjem“ PDF dokumenta u novi PDF dokument.

Informacioni sistem APR-a za dostavljanje finansijskih izveštaja ove godine dolazi sa novom klijentskom aplikacijom NexU-APR koja se koristi za pristup kriptografskom uređaju za formiranje potpisa (token ili pametna kartica). Kako autori opisuju:

Ovo je aplikacija za formiranje elektronski potpisanih dokumenata iz internet pregledača, na klijentskoj strani. Rešenje je bazirano na DSS radnom okviru i NexU aplikaciji, čiji je naručilac Evropska komisija, a implementator kompanija Nowina Solutions.

Evropski Digital Signature Service je projekat slobodnog softvera koji nudi sveobuhvatno rešenje za izradu, proveru i čuvanje elektronskih potpisa u različitim formatima. Poseban akcenat projekta je priprema potpisanih dokumenata za dugoročno arhiviranje.

Klijentska aplikacija NexU izvorno podržava Microsoft Windows, GNU/Linux i macOS, ali je u domaćoj verziji aplikacija zvanično podržana samo na Windowsu, i to verzijama nakon XP-a.

Ipak, programeri su ostavili konfiguraciju za učitavanje midlvera Pošte na GNU/Linuxu. Sertifikaciono telo Pošte je jedino domaće sertifikaciono telo koje izdaje kvalifikovane sertifikate za elektronski potpis (KES) sa midlverom koji radi na macOS-u i GNU/Linuxu.

To znači da je informacioni sistem APR-a i potpisivanje dokumenata preko aplikacije moguće koristiti i na GNU/Linuxu. Bez ikakvih izmena prepakovao sam aplikaciju NexU-APR i priredio instalacioni paket za Debian/Ubuntu koji sadrži i zgodnu skripticu za pokretanje. Dostupna je i obična .tar.gz arhiva za ostale distribucije. Moguće bi bilo napraviti i macOS instalaciju, ali nemam hardver na kome bi to učinio.

SafeSign midlver

Za korišćenje aplikacije je neophodno da instalirate AET SafeSign midlver koji tražite od Pošte. Alternativno instalaciju midlvera možete naći i na internetu, najčešće na brazilskim sajtovima gde je državno korišćenje GNU/Linuxa daleko veće nego kod nas.

Poslednja verzija midlvera koju ja imam je dosta stara 3.0.97 i na novijim Ubuntu distribucijama potrebno je instalirati stare libtiff4, libwxbase2.8 i libwxgtk2.8 pakete. Oni se takođe lako pronalaze na pomenutim sajtovima. Pokrenite tokenadmin da proverite instalaciju čitača i midlvera, te da li vidite sertifikat u listi.

NexU APR klijentska aplikacija

NexUApr(1.0)

Instalacioni paket za Ubuntu/Debian

Za druge distribucije dostupna je obična arhiva NexUApr-1.0.tar.gz koju preporučujem da raspakujete u /opt kako ne bi morali da menjate putanje u skripti za pokretanje. Program zahteva java-jre i zenity, a midlver traži još i pcscd.

Nakon instalacije pokrenite NexUApr prečicu. Aplikacija pri prvom pokretanju generiše par ključeva i samopotpisani localhost sertifikat koji je potrebno da dodate u veb pregledaču. Alternativno možete dodati sigurnosni izuzetak bez instalacije sertifikata.

Korišćenje samopotpisanog sertifikata i klijentske aplikacije je postalo uobičajno rešenje umesto ranije korišćenih Java apleta. Sertifikat je neophodan kako bi se ostvarila komunikacija između veb aplikacije na HTTPS protokolu i lokalnog servera koji time mora takođe da implementira HTTPS protokol. Par ključeva i sertifikat mogu biti generisani unapred (zajednički za sve korisnike) što olakšava instalaciju (kod nas primer je CROSO) ili kao u slučaju NexU aplikacije da se generišu pri prvom pokretanju. Aplikacija bi teorijski mogla da sertifikat/izuzetak postavi samostalno, bez potrebe za intervencijom korisnika, ali u praksi postoji prevelika raznolikost odgovarajućih skladišta, putanja instalacije, profila i verzija veb pregledača.

Rešenja zasnovana na Native Messaging tehnologiji ne traže dodavanje izuzetaka, ali umesto jedne komponente (klijentska aplikacija) dolaze u dva dela (aplikacija i ekstenzija za veb pregledač) pa je potrebno posebno pakovanje za Chrome, Firefox, Edge (ako postane podržan).

Vratimo se APR aplikaciji, pri pokretanju skripta će prikazati sledeće prozorče:

Bezbednosno obe opcije su jednake i u ovom slučaju ne predstavljaju rizik. Ako odaberete opciju da dodate izuzetak prikazaće se localhost link koji treba da otvorite u veb pregledaču. Mozilla Firefox nudi opciju dodavanja izuzetka nakon što kliknete na dugme Advanced pa Add Exception, dok Google Chrome traži da „na slepo“ ukucate badidea.

Nakon što dodate izuzetak umesto upozorenja, prikazaće se ikonica aplikacije. To je potvrda da je komunikacija omogućena.

Ukoliko se opredelite da instalirate sertifikat, sačuvajte datoteku i zatim iz terminala programom certutil dodajte sertifikat u odgovrajuće skladište za Google Chrome, odnosno Mozilla Firefox. Skoro sigurno će biti lakše dodati izuzetak, a u Firefoxu između dva i ne postoji razlika pošto dodavanje izuzetka zapravo upravo dodaje sertifikat aplikacije.

Kada ste završili instalaciju možete da pristupite APR aplikaciji za elektronsko potpisivanje dokumenata. Otvorite stranicu aplikacije i klikom naPokreni potpisivanje možete da odaberete PDF ili XML datoteku sa računara.

U prozoru za izbor tokena trebalo bi da već bude prepoznato sertifikaciono telo Pošte, zajedno sa parametrima za pristup midlveru (/usr/lib/libaetpkss.so.3).

Unesite PIN, izaberite sertifikat i sačuvajte potpisani dokument. Detaljnu proveru potpisa možete da obavite preko demo instalacije aplikacije za validaciju iz pomenutog evropskog DSS ili na Windowsu u programu Adobe Reader.

Slobodan softver uglavnom podržava proveru i zanavljanje potpisa na strani servera, ili su u pitanju rešenja namenjena drugim programerima. Gotovi programi namenjeni korisnicima su malobrojni. Za izradu potpisanog PDF-a mogu da se koriste programi LibreOffice i jSignPdf.

Program pdfsig iz projekta poppler ima osnovnu PAdES implementaciju. Ukoliko bi se podrška unapredila, potpis bi mogao da bude prikazivan i validiran direktno u popularnim programima za prikaz PDF dokumenata kao što su evince ili kpdf. Nešto bolja podrška od nedavno postoji u LibreOfficu, ali ni on nije u mogućnosti da validira potpis iz APR-a.

Neobično je što dokument potpisan na ovaj način nema ugrađen vremenski žig što bi APR svakako bio u mogućnosti da obezbedi u okviru postojeće državne infrastrukture, za razliku od korisnika koji tu uslugu moraju dodatno da plate. Na taj način bi se izbegla situacija da potpis prestaje da važi istekom ili opozivom sertifikata što se kod nekih drugih e-servisa (Fond PIO) već javljalo kao problem iz prakse. Potpisani dokument sadrži lanac sertifikata i podatke za proveru, u slučaju Pošte kao OCSP odgovor. Potpis se dodaje kao „nevidljivi“ potpis i odnosi se na ceo dokument.

Klijentska aplikacija NexU-APR nije ogovarajuće podešena za korisnike 64bitne verzije Windowsa, kada se koristi PKCS#11 kao metod pristupa tokenu, a posebno problem imaju korisnici sertifikata sertifikacionog tela Halcom čak i kada instaliraju novu verziju Nexus Personal midlvera.

Kod 32bitnog Windowsa svi programi i komponente su 32bitni pa ne dolazi do zabune. Međutim kod 64bitnog Windowsa moguće je pokretati i 32bitne i 64bitne programe pa je potrebno tačno upariti Javu, klijentsku aplikaciju i PKCS#11 modul.

NexU-APR aplikacija dolazi sa sopstvenom instalacijom Jave. Zato instalacioni paket ima čak 80 megabajta, ali je zgodno što će makar Java biti ispravno podešena. Ova verzija Jave je 32bitna, pa bez obzira imate li 64bitni ili 32bitni Windows kada instalirate i pokrenete NexU-APR aplikaciju koristićete 32bitnu Javu. To će nam kasnije biti značajno.

Instalacija midlvera

Instalacije midlvera uglavnom dolaze u različitoj varijanti za 32bitni i 64bitni Windows (AET SafeSign za korisnike Pošte, TrustEdgeID za PKS/MUP/Vojsku, te RSIDCardMW za stare lične karte). Ukoliko koristite 64bitni Windows potrebno je da instalirate 64bitnu verziju instalacije midlvera.

Nexus Personal za Halcom sertifikate u sebi sadrži obe verzije, dok IDPrime za korisnike sertifikacionog tela E-Smart ima deo koji zavisi od „bitnosti“ sistema, i zajedničku instalaciju za PKCS#11 modul.

TrustEdgeID dolazi u dve verzije, postoji stara verzija koja ima odvojenu instalaciju za PKS i MUP, te nova verzija (dostupna sa sajtova sertifikacionog tela PKS i Vojske) koja podržava rad sa karticama i tokenima sva tri tela. Instalacija nove zajedničke verzije uklanja odvojene instalacije.

PKCS#11 moduli

Sve pomenute 64bitne instalacije midlvera kada se instaliraju u sebi sadrže i 32bitnu i 64bitnu verziju PKCS#11 modula. U pitanju je .dll datoteka koja se nakon instalacije nalazi negde na računaru. Ovaj modul se najčešće naslanja na Windows i midlver sa kojim korisnik interaguje preko nekog pomoćnog programa (npr. Token Manager, Token Administrator,…).

Drugi programi (Mozilla Firefox ili u ovom slučaju NexU-APR) mogu da učitaju PKCS#11 modul i tako koriste pametnu karticu ili token za kriptografske operacije. Na taj način programi mogu da podrže različite uređaje, pod uslovom da uređaj poseduje ispravan PKCS#11 modul koji korisnik može da učita u program.

Izbor PKCS#11 modula u NexU-APR aplikaciji

Kako se NexU-APR pokreće 32bitnom Javom bez obzira da li koristite 32bitni ili 64bitni Windows, potrebno je da se u aplikaciji odabere 32bitni PKCS#11 modul.

Kada koristite 32bitni Windows situacija je jasna - sve je 32bitno i problema nema. Ali ako imate 64bitni Windows, potrebno je da prvo instalirate 64bitnu instalaciju midlvera, ali zatim da u NexU-APR aplikaciji odaberete putanju za 32bitni PKCS#11 modul! Ako bi u tom slučaju pokušali da u NexU-APR aplikaciji odaberete 64bitni modul prikazaće se greška:

Opis greške nije tačan. Greška se javlja jer biblioteka ne odgovara Javi (koja je 32bitna), a ne zato što ne odgovara sistemu.

Putanja do 32bitnog PKCS#11 modula može da se razlikuje na 32bitnom i na 64bitnom sistemu. Zato evropski projekat DSS NexU na kome je zasnovana APR-ova aplikacija omogućava programerima da u konfiguraciji aplikacije navedu jednu putanju do 32bitnog PKCS#11 modula na 32bitnom i drugu do istog modula na 64bitnom Windowsu. Kada se ispravno podesi, olakšava se korisnicima jer se automatski bira prava putanja. Međutim programeri koji su priredili APR-ovu aplikaciju su ovo izgleda pogrešno razumeli i u drugom slučaju naveli putanje do 64bitnih modula što dovodi do gore prikazane greške.

Igrom slučaja, izuzev kod Halcoma, kod svih su putanje do 32bitnog modula iste i na 32bitnom i na 64bitnom Windowsu.

To znači da ako koristite 64bitni Windows, dok programeri ne isprave konfiguraciju, u NexU-APR aplikaciji obavezno kliknite na detaljna podešavanja i zatim izaberite 32bitnu varijantu odgovarajućeg modula pre nego što nastavite.

Korisnici Halcom sertifikata moraju da izmene putanju, pošto se tu razlikuju i nije moguće da se na 64bitnom Windowsu samo izabere ponuđena 32bitna putanja.

Tačne putanje do 32bitnog PKCS#11 modula za midlvere tokena sertifikacionih tela u Srbiji su date u tabeli.

Kako da izmenite putanje u NexU-APR?

Da izmenite podešavanja, na primer za MUP, izaberite u listi Sertifikaciono telo MUP Republike Srbije pa kliknite na Detaljna podešavanja. Zatim odaberite TrustEdgeID - 64bit kako bi popravili tu putanju, pa kliknite naIzmeni. U prozorčetu koje će se otvoriti kliknite na dugme Odaberi, a potom u polje na dnu kopirajte putanju iz tabele.

Potvrdite klikom na Open ili Otvori i zatim kliknite na Prihvati.

Postoji i donekle jednostavan način da trajno ispravite sve putanje odjednom.

Preuzmite ovu ZIP arhivu i otvorite je. U njoj se nalazi XML datoteka sa podešavanjima koja ćemo ubaciti u NexU aplikaciju. Ukoliko je aplikacija pokrenuta, najpre zatvorite NexU desnim klikom na ikonicu pored sata, pa iz menija izaberite Izlaz i sačekajte da ikonica nestane.

Sada treba da otvorimo fasciklu (folder) sa podešavanjima NexU aplikacije i to tako što na tastaturi istovremeno pritisnete Win taster i taster R, ili iz Start menija odaberite opciju Run/Pokreni. Kopirajte%userprofile%\.NexUApr u polje za unos i kliknite Ok, odnosno U redu.

Ukoliko uradite tako, otvoriće se fascikla sa NexU podešavanjima.

Prevucite XML datoteku iz ZIP arhive u fasciklu sa podešavanjima NexU aplikacije, menjajući postojeću. Pokrenite ponovo NexU aplikaciju i sve putanje će biti ispravne, a među putanjama za Sertifikaciono telo MUP-a dobićete i dodatnu opciju sa putanjom za novi TrustEdgeID midlver.

Novi TrustEdgeID midlver

Novi zajednički TrustEdgeID midlver podržava nove lične karte (od 18.8.2014), kartice i tokene Privredne komore Srbije i sertifikacionog tela Vojske Srbije. Dostupan je za preuzimanje sa sajtova PKS i Vojske, a njegova instalacija će obrisati prethodne odvojene instalacije za MUP i PKS, pa postojeće putanje u NexU aplikaciji neće raditi.

Pri pravljenju liste dostupnih sertifikata NexU-APR aplikacija prihvata samo one sertifikate koji odgovaraju izabranom sertifikacionom telu, dok će ostali sertifikati biti prikazani sa crvenim kružićem kao nevalidni.

To znači da ukoliko koristite zajednički midlver u NexU-APR aplikaciji morate da dodate i opciju sa putanjom do zajedničkog modula prema tabeli iznad, unutar ponuđenih putanja za Sertifikaciono telo MUP Republike Srbije.

Ove putanje već postoje među ponuđenima za PKS pa tu neće biti problema.

Aplikacija NexU-APR nema podršku za sertifikate koje izdaje sertifikaciono telo Vojske Srbije kada se koristi PKCS#11 kao metod pristupa tokenu. Moguće da podrška postoji kada se koristi Windows skladište sertifikata. Do sada nikada nisam video dokument potpisan takvim sertifikatom i ne znam kome su sertifikati dodeljeni niti koliko ih je izdato.

Oznaka slota

Kod PKCS#11 modula oznaka slota zavisno od implementacije modula može da označava redni broj čitača kartica ili tokena, ili redni broj kontejnera unutar jednog tokena ili kartice.

Ukoliko koristite više čitača kartica na računaru, ili ste nekada imali drugi čitač, ili koristite tokene (što je zapravo čitač kartica i kartica spojeno u jednom uređaju) najverovatnije ćete morati da podešavate i slot. Nažalost, mislim da nema lakog načina da saznate pravu vrednost već morate da isprobavate.

Isprobajte uvek najpre slot 0.

Ako se prikaže ova greška, a sigurni ste da ste izabrali pravo sertifikaciono telo i vidite sertifikate u pratećoj aplikaciji (Token Administrator, Token Manager, Nexus Personal...) znači da aplikacija traži sertifikate na pogrešnom mestu, pa povećajte slot za 1 i pokušajte ponovo.

Ako se prikaže ovakva greška, znači da smo preterali sve slotove (obratite pažnju na deo poruke „but token only has ... slots“), pa smanjite slot za 1 i pokušajte ponovo.

Zavisno od redosleda korišćenja tokena i kartica oznaka slota može da se promeni. Ne mora da znači da token koji je ranije radio sa slot 1, sada neće zahtevati slot 0 i obrnuto.

Biću zahvalan ako u komentaru napišite efikasniji način da se odredi prava vrednost slota, posebno ako imate programersko iskustvo u radu sa PKCS#11 modulima.

Srećno u potpisivanju!

Stari sertifikati MUPCA u kojima je kao izdavalac upisan „MUPCA Građani“ ili „MUPCA Građani 2“ imaju poznati propust gde su serijski brojevi sertifikata neispavno zapisani sa vodećim nulama, suprotno standardu za X.509 sertifikate i pravilima ASN.1 kodiranja. Za problem se zna od 2010. godine. MUP je 2014. godine prešao na nove sertifikate i oni u kojima je kao izdavalac upisan „MUPCA Građani 3“ su ispravni i nemaju ovaj problem.

Nije mi poznato koliko starih sertifikata je još uvek važeće, niti da li je moguće dobiti novi sertifikat na ličnoj karti sa starim čipom (kartice izdate pre 18.8.2014).

Problem sa starim sertifikatima u nekim programima sprečava njihovo korišćenje. Za korišćenje u bilo kom programu zasnovanom na openssl biblioteci (na primer prijava klijentskim sertifikatom na veb serveru) potrebno je koristiti posebno prepravljenu openssl biblioteku.

Nova verzija Jave 8u121 objavljena 17. januara ove godine kao ispravku nepovezanog sigurnosnog propusta dodaje i proveru koja ove stare sertifikate čini neupotrebljivim u programima zasnovanim na Javi. Izmena nosi oznaku JDK-8168714 i uključena je u Java 8 u121, Java 7 u131, Java 6 u141 i sva novija izdanja, uključujući i OpenJDK distribuciju Jave.

More checks added to DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed indefinite length encoding will now lead to IOException during parsing. Note that signatures generated using JDK default providers are not affected by this change. (JDK-8168714)

Za korisnike ovo znači da kada se izvrši ažuriranje Jave servisi ePorezi ili CROSO više ne rade sa starim sertifikatima MUP-a koji kao izdavaoca imaju MUPCA Građani ili MUPCA Građani 2. Na servisu ePorezi ne vidi se konkretna greška već uopštena poruka „Na kartici ne postoji sertifikat sa podacima o JMBG“ koja može da označava i druge probleme. Na CROSO portalu se prikazuje tačna greška „Invalid encoding: redundant leading 0s“ koja nam ukazuje na problem.

Rešenje je zamena sertifikata novim čiji je izdavalac MUPCA Građani 3, ili privremeno vraćanje Jave na stariju verziju 8u112. Instalacija starije Java 8u112 za Windows je dostupna ovde ili prateći Java Archive link na zvaničnom Oracle sajtu.

Java veb aplikacije

Nadogradnja Java okruženja će pogoditi i sve veb aplikacije koje čuvaju, primaju ili validiraju sertifikate i potpise. Problem možemo da ilustrujemo trivijalnim kodom koji učitava X.509 sertifikat:

import java.io.FileInputStream;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;

public class LoadCert {
  public static void main(String args[]) throws Exception {
    FileInputStream in = new FileInputStream(args[0]);

    CertificateFactory cf = CertificateFactory.getInstance("X.509");
    Certificate trust = cf.generateCertificate(in);

    System.out.println("ok");
  }
}

$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.10.2-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

$ java LoadCert MUPCARoot.crt
Exception in thread "main" java.security.cert.CertificateParsingException: java.io.IOException: Invalid encoding: redundant leading 0s
	at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:169)
	at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1804)
	at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:195)
	at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:102)
	at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
	at MainClass.main(MainClass.java:27)
Caused by: java.io.IOException: Invalid encoding: redundant leading 0s
	at sun.security.util.DerInputBuffer.getBigInteger(DerInputBuffer.java:152)
	at sun.security.util.DerValue.getBigInteger(DerValue.java:512)
	at sun.security.x509.SerialNumber.construct(SerialNumber.java:44)
	at sun.security.x509.SerialNumber.<init>(SerialNumber.java:86)
	at sun.security.x509.CertificateSerialNumber.<init>(CertificateSerialNumber.java:102)
	at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:643)
	at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:167)
	... 5 more

$ java LoadCert MUPCARoot3.crt
ok

Na staroj verziji Jave 8u112, oba sertifikata se ispravno učitavaju:

$ $JAVA_HOME/bin/java -version
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)

$ java LoadCert MUPCARoot.crt
ok

$ java LoadCert MUPCARoot3.crt
ok

Moguće zaobilazno rešenje je prirediti poseban JRE koji ne sadrži proveru dodatu kroz JDK-8168714, ali sadrži druge bezbednosne ispravke.

Ispravka dolazi u sigurnosnim nadogradnjama za RHEL verzija 5, 6 i 7 kao i za sve druge poznate distribucije, odnosno drugi softver koji sadrži zakrpu za CVE-2016-5546, pa se može dogoditi da se verzija Jave nadogradi i ako ne menjate postavke svoje aplikacije.

Ovaj citat odlično opisuje situaciju: