Goran Rakić

Nova Java i stari sertifikati MUPCA

Sun, 19 Feb 2017 01:45:00 +0100

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:

APR NexU i bitnost Windowsa

Mon, 13 Feb 2017 23:20:00 +0100

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.

Tehnička napomena za programere aplikacija...

Alternativa PKCS#11 modulima je da programi koriste uslugu Windows operativnog sistema (u NexU-APR aplikaciji ovo je opcija „Microsoft skladište ključeva“) kada se zaobilazi PKCS#11 modul i tokenima pristupa kroz Microsoft CryptoAPI (skraćeno MS-CAPI).

Sa oba je moguće postići sličan rezultat, a izbor uglavnom zavisi od mogućnosti tehnologije kojom se pravi aplikacija. Midlveri za tokene i kartice koje koriste domaća sertifikaciona tela podržavaju oba interfejsa, iako bi teorijski mogao da postoji token koji ima samo PKCS#11 ili samo MS-CAPI podršku. Pristupom kroz PKCS#11 veći akcenat se stavlja na uređaj koji sadrži objekte (ključevi, sertifikati) i nudi operacije. Pristupom kroz MS-CAPI dobija se lista instaliranih sertifikata u Personal skladištu, bez obzira u kom uređaju se nalaze, a operacije sprovodi operativni sistem preko registrovanog midlvera.

Programi koji učitavaju PKCS#11 module mogu da rade i na drugim operativnim sistemima (pod uslovom da je i odgovarajući PKCS#11 modul dostupan za taj sistem), dok je MS-CAPI interfejs dostupan samo na Windowsu.

Midlver može da ima različiti kvalitet implementacije ova dva interfejsa, pa tako neki token može da radi pouzdano kada mu se pristupa kroz MS-CAPI, a da izaziva rušenje aplikacije kada korisnik pokuša da koristi PKCS#11 modul. Ili može da ne vidi ili prikazuje ranije uočene sertifikate kroz MS-CAPI, a da sasvim ispravno radi kroz PKCS#11 interfejs.

Kada se koristi MS-CAPI u kombinaciji sa pametnim karticama i tokenima Windows automatski poziva midlver prema ATR vrednosti, dok u slučaju PKCS#11 interfejsa taj deo mora da odradi aplikacija ili da prepusti korisniku da ručno izabere modul.

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.~~ APR NexU aplikacija inicijalno učitava prvi PKCS#11 modul na koji naiđe, uopšte ne proveravajući bitnost Jave i operativnog sistema. U konfiguraciji 64bitne putanje su navedene prve, pa ih aplikacija inicijalno nudi kada postoje nakon instalacije 64bitnog midlvera. Programeri 64bitne putanje nije trebalo da navode u konfiguraciji pošto nikako ne mogu da rade sa 32bitnom Javom. Ispravno rešenje bi bilo prepoznati bitnost samog Windowsa *), a zatim učitati putanju do 32bitnog PKCS#11 modula pošto znamo da aplikacija dolazi sa svojom 32bitnom Javom.

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.

Naziv midlvera	32bitni modul na 32bitnom Windowsu	32bitni modul na 64bitnom Windowsu
AET SafeSign (Pošta)	C:\Windows\System32\aetpkss1.dll	(koristi se ista putanja, vidi napomenu)
Nexus Personal (Halcom)	C:\Program Files\Personal\bin\personal.dll	C:\Program Files (x86)\Personal\bin\personal.dll
RSID Card MW (MUP, lične karte pre 18.8.2014)	C:\Program Files\MUP RS\Republic of Serbia ID Card Middleware\rsidp11_x86.dll
MUP TrustEdgeID	C:\Program Files\NetSeT\TrustEdgeID\netsetpkcs11_x86.dll
PKS TrustEdgeID (stari)	C:\Program Files\NetSeT\TrustEdgeID PKS\netsetpkcs11_x86.dll
TrustEdgeID (novi zajednički za PKS/MUP/VS)	C:\Program Files\TrustEdgeID\netsetpkcs11_x86.dll
IDPrime (E-Smart)	C:\ESSQCA\pkcs11\IDPrimePKCS11.dll

Napomena: U slučaju AET SafeSign midlvera na 64bitnoj Windows instalaciji Windows-on-Windows podsistem automatski vrši prepravku putanje sa C:\Windows\System32\aetpkss1.dll na C:\Windows\SysWOW64\aetpkss1.dll. Zato korisnici Pošte nemaju posebne 32bitne i 64bitne putanje.

Izvor: Putanje pkcs#11 midlvera sertifikacionih tela u Srbiji

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 na Izmeni. 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!

APR NexU elektronski potpis na GNU/Linuxu

Mon, 06 Feb 2017 15:06:00 +0100

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

unsignpdf - uklonite e-potpis iz PDF dokumenta

Thu, 26 Jan 2017 00:54:00 +0100

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

Obračun kod CROSO portala

Wed, 11 Jan 2017 17:33:00 +0100

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.

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.

Pravilnik o bližim uslovima za izdavanje sertifikata, Sl. glasnik RS, br. 26/2008

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.

Primer lažnog google.rs sertifikata koji bi napadač mogao da iskoristi

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.

Automatsko dodavanje izuzetka, bez intervencije 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.

Pristup CROSO portalu

Sat, 24 Dec 2016 17:50:00 +0100

Nova verzija SecurityTray aplikacije je objavljena 9. januara 2017. godine koja više ne koristi opozvani sertifikat. Tekst ispod se odnosi na pretodnu verziju i više nije primenljiv. Za informacije o pristupu, pratite nova uputstva na CROSO portalu. Hvala svima koji su se lično javili kako bi zahvalili za dole napisani savet u vezi pristupa portalu od 23. do 30. decembra. Drago mi je da sam mogao da pomognem. Tekst ostavljam objavljen na blogu radi potpune arhive.

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

Čitanje lične karte bez Java apleta

Tue, 20 Dec 2016 00:15:00 +0100

Opet o apletima

Godina na ovom blogu počela je tekstom „Odzvonilo“ za Java aplete u kome sam pokušao da objasnim zašto je Java apletima, iako je to danas tehnologija na zalasku, omogućen razvoj različitih inovativnih rešenja e-uprave i e-poslovanja.

Programeri su Java apletima obećavali jednostavnu distribuciju malih programčića koji dozvoljavaju pristup kriptografskim uređajima (pametnim karticama i tokenima) koji će raditi u svim popularnim pregledačima i na svim operativnim sistemima gde postoji Java podrška. Od 2006. godine gotovo sve ranije korišćenje komponente (ActiveX, npr. MS CAPICOM) učestalo se menjaju apletima, a klijentske aplikacije menjaju se web rešenjima.

Iako korisnici aplete i ne vole, ko se na primer sreo sa podešavanjem za pristup ISPP+ servisu Uprave za Trezor siguran sam radije će raditi sa 10 apleta nego ovom kombinacijom zastarele klijentske aplikacije, ActiveX kontrole i nevalidnih SSL sertifikata što konačno zahteva „spuštanje sigurnosti na minimum“ i korišćenje starih verzija Windowsa. Samo pogledajte zastrašujuće uputstvo!

Java apleti, kao metoda koja dozvoljava pokretanje programčića na računarima korisnika prirodno predstavlja i sigurnosni rizik. Ne postoji razlika između klika na virus u email poruci i pokretanje zlonamernog apleta sa bilo kog sajta. Zato iz verzije u verziju Jave dodavale su se nove kontrole kojima se ograničava „divlje i slobodno“ pokretanje te od korisnika zahteva da eksplicitno potvrde svoju svesnu želju da pokrenu aplet. Od programera se zahtevalo da poštuju najnovije savete najbolje prakse. Korisnicima treba omogućiti da lako pokrenu pouzdani aplet za pristup e-bankarstvu, ali istovremeno treba onemogućiti pokretanje zlonamernih apleta na drugim sajtovima. Zato aplet mora da bude ispravno potpisan sertifikatom koji je moguće nezavisno proveriti (kako bi korisnici znali da je autor pouzdan), aplet mora da bude isporučen sa obezbeđenih stranica (HTTPS), da se rad omogući samo na određenim stranicama (podaci u manifestu apleta) itd. Ukoliko se to ne isprati, korisnici dobijaju gomilu upozorenja, moraju da isključuju sigurnosne zaštite (čime dovode svoj računar i podatke u opasnost) i ako se u tome ne snađu, na kraju verovatno odustanu od modernog servisa e-uprave.

Drugo obećanje o Java apletima koji rade u svim pregledačima i sistemima takođe ne dolazi automatski. Programeri treba da imaju u vidu specifičnosti svakog sistema i izbegnu da naprave greške zbog kojih bi aplet radio samo na Windowsu. Kod nas poznat primer je aplet za pristup servisu ePorezi Poreske uprave, gde sam još 2014. godine objavio jednostavnu ispravku kako bi aplet radio i na GNU/Linuxu i macOS-u. Autori apleta su isključili podrazumevano učitavanje komponente za rad sa pametnom karticom koje radi svuda, i onda definisali svoju implementaciju, verovatno želeći da olakšaju korišćenje, ali u tome uradili samo podršku za Windows. Pih.

Alternative

Tekst o apletima sa početka godine je završio pričom o alternativama. Na primer za pristup CROSO portalu danas se koristi Java aplikacija koja treba da bude pokrenuta u pozadini. Korisnici najčešće program drže stalno pokrenut, iako je moguće i ručno pokretati i zaustavljati ga pre i nakon rada.

Drugi pristup je veoma sličan, sa razlikom da pokretanje i gašenje aplikacije možemo da prepustimo samom veb pregledaču. Instalirani dodatak (engl. Add-on) ili ekstenzija tada može da obezbedi taj dodatni pristup veb stranici kako bi se razmenili podaci sa čitačem kartica. Ipak izrada posebnih ekstenzija za svaki browser i operativni sistem nije isplativo rešenje.

Google Chrome, Mozilla Firefox, Opera, Microsoft Edge postepeno usvajaju zajedničku specifikaciju za web ekstenzije (WebExtensions) gde jedan njen deo Native Messaging omogućava upravo saradnju veb stranice (sajta), ekstenzije i programčeta u pozadini.

Korisniku se nudi instalacioni paket za odgovarajući operativni sistem koji sadrži programče. Instalacijom programče postaje dostupno pregledaču, ali se ne pokreće automatski. Instalacioni paket postavlja i dodatak/ekstenziju koja će obezbediti dodatnu funkcionalnost jednom ili svim sajtovima koji imaju potrebu da je koriste.

Native Messaging ekstenzija za čitanje lične karte

Kao proof-of-concept, razvio sam kod ekstenzije koja koristi raniju Java biblioteku JFreesteel za čitanje lične karte (open-source kod ove biblioteke programeri koriste u većem broju sistema za brzi unos podataka i podršku prodaji, softveru za osiguranje, platne usluge, ali i na portalu eUprava).

Kada je instalirana ekstenzija se prikazuje u Google Chrome browseru:

Programče za podršku i odgovarajući Native Messaging manifest su instalirani posebno.

Ekstenzija se sastoji od content skripte koja je dostupna svim veb stranicama i deljene background skripte. Uloga background skripte je da upravlja kanalima za komunikaciju sa pratećim programom (svaki tab dobija posebnu instancu programčeta i kanal za komunikaciju) i prosleđuje podatke između programčeta i content skripte.

Ekstenzija ne radi ništa sve dok korisnik ne poseti stranicu koja želi da pristupi čitaču i pročita ličnu kartu.

Učitavanjem testne veb stranice najpre se kreiraju kanali za komunikaciju, a zatim se u pozadini pokreće programče za čitanje lične karte. Ubacivanjem kartice u čitač, podaci postaju dostupni u veb stranici koja je inicirala čitanje. Moguće je koristiti više čitača i vršiti više očitavanja, zavisno od potreba veb aplikacije.

Napuštanjem stranice zatvaraju se kanali za komunikaciju, i zaustavlja prateće programče iz pozadine.

Kod je kao i JFreesteel biblioteka dostupan na GitHubu pod GNU LGPLv3 licencom koja dozvoljava i komercijalno korišćenje (uz određene uslove vezane za objavljivanje unapređenja same biblioteke).

U pitanju je proof-of-concept namenjen programerima.

Za korišćenje u gotovom rešenju neophodno je razraditi pakovanje i distribuciju pratećeg programčeta (instalacioni paket sa sistemskom ili korisničkom instalacijom) za različite operativne sisteme, objavljivanje ekstenzije i njenu doradu kako bi pružila informacije i pomoć korisniku u vezi instalacije pratećeg programčeta. Potrebno je i dodatno ograničiti rad ekstenzije na samo određenim sajtovima (sajt usluge za koju se implementira čitanje lične karte) ili u slučaju da je ekstenzija dostupna na svim sajtovima, dodati opciju korisniku da ovlasti ili spreči čitanje dokumenta na određenom sajtu.

Ekstenzija trenutno radi samo u Google Chromu, ali podrška za tehnologiju postoji i u drugim pomenutim browserima. Razvoj ovakvog rešenja je nužno kompleksniji od Java apleta, ali korisnički doživljaj može biti na uporedivom nivou.

U odnosu na klijentsku aplikaciju (kako to radi CROSO), ima nešto više posla, ali se postiže bolja spregnutost browsera i pratećeg programčeta, te izbegavaju eventualni problemi sa lokalnim mrežnim postavkama i zaštitama, te CORS restrikcijama. Na primer, neće vam trebati saradljivo serifikaciono telo (PKS CA) da izda CN=localhost SSL web sertifikat i ne opozove ga iako privatni ključ podelite javno kao deo instalacije.

WebExtensions Native Messaging API

Nastao je u Google Chromu kao rešenje nakon prestanka podrške za NPAPI (Netscape Plugin API) tokom 2015. godine. API je podržan i od Mozilla Firefoxa verzije 50, a čeka se na prvu objavu u Microsoft Edge pregledaču. Opera takođe podržava ovaj API, dok Safari nije podržan i zahtevao bi neko alternativno rešenje.

Mobilne platforme nisu podržane.

Tehnologija omogućava podršku za sve operativne sisteme, ali je za svaki potrebno napraviti instalacioni paket koji će postaviti prateću aplikaciju i manifest kojim se ista registruje u veb pregledaču.

Custom EDID for intel i915 KMS on Fedora

Tue, 09 Aug 2016 19:25:00 +0200

Recently I started using my old DELL U2412M monitor on a system with integrated Intel graphics. As the motherboard exposes HDMI output only, and my monitor has DVI-D, I used some cheap passive DVI-D to HDMI adapter signal adapter. Unfortunately in this setup the card was not able to receive EDID info. Combine that with early KMS enabled on Fedora, all I could get is a blank screen with a timing error warning.

It is possible to set custom EDID on Fedora following these steps:

Get a valid EDID file

This is a file I found online (U2412M.bin), and quickly checked it with a parse-edid tool. It is also possible to extract valid EDID from another system, where EDID is correctly recognized.
Move the file to /usr/lib/firmware/edid
Edit grub config file

Edit /etc/defaults/grub and add this option to GRUB_CMDLINE_LINUX:

drm_kms_helper.edid_firmware=HDMI-A-1:edid/U2412M.bin

I also set video=HDMI-A-1:D option to force output to be connected even if I disconnect the cable.

Regenerate the grub config file with grub2-mkconfig > /boot/grub2/grub.cfg
Rebuild initramfs

KMS is set early, from initramfs so we need to include our EDID file in the generated initrd.

I’ve added install_items+=" /usr/lib/firmware/edid/U2412M.bin " to /etc/dracut.conf.d/99-local.conf and used dracut -f to rebuild the active initrd.

Check with lsinitrd that the EDID file is included.
Reboot

Solved, and no need for these HDMI dummy plug - EDID emulator!

References:

„Odzvonilo“ za Java aplete

Thu, 28 Jan 2016 22:25:00 +0100

Da li prestaju da rade veb aplikacije banaka i e-uprave?

U zvaničnoj objavi na Oracle blogu od 27. januara među programerima je odjeknula vest da će u narednoj verziji 9 Java platforme apleti postati zastarela tehnologija, pre nego što podrška za Java aplete potpuno ne nestane u budućim izdanjima Java platforme.

Najpre da naglasim, nema mesta za paniku. Sve veb aplikacije za e-bankarstvo koje rade sa apletima i pametnim karticama, e-Porezi, APR aplikacija za finansijske izveštaje i slične će raditi (ili neće raditi - kako kome i kako gde) i sutra i sledeće nedelje isto kao i do danas. Jedino su veb aplikacije koje koriste Java aplete „na udaru“. Ništa se ne menja kod nezavisnih aplikacija za e-bankarstvo koje se posebno instaliraju na računaru kao ni kod mobilnih aplikacija.

Vest je ipak značajna za programere ovih veb aplikacija i sve one koji planiraju budući razvoj i donose tehničke odluke o izboru tehnologije. Sada je vreme da se predvidi i planira ažuriranje aplikacija, pre nego što podrška za Java aplete istekne.

Java apleti su tehnologija koja omogućava transparetno pokretanje programa direktno iz veb pregledača. Kako ime tehnologije ukazuje, ovi programi pisani su na programskom jeziku Java (ili nekom od njemu srodnih jezika), danas verovatno najpopularnijem programskom jeziku. Kada korisnik poseti veb stranicu sa Java apletom, učitava se program koji zatim može da interaguje sa računarom, uređajima i podacima korisnika povezujući ih sa veb stranicom.

Apleti postoje još od devedesetih, a sve do poslednje decenije i renesanse JavaScripta¹ i HTML5 bili su prihvatljivo tehnološko rešenje za veb aplikacije koje su trebale da naprave „nešto više“ - izvedu interaktivna izračunavanja, pokrenu komunikaciju u realnom vremenu, prikažu naprednu grafiku ili povežu veb aplikaciju sa drugim uređajima korisnika. Deo ovih mogućnosti nudio je i Adobe Flash Player, a kako je donosio nešto bolji korisnički doživljaj, Flash je postao popularniji izbor kada god je to bilo moguće (video stream, komunikacija, pristup mikrofonu i kameri, interaktivne igre…).

Od 2004. godine Java 1.5 dolazi sa ugrađenom podrškom za rad sa kriptografskim uređajima (PKCS#11 API), a krajem 2006. Java 1.6 je programerima omogućila lak direktni pristup pametnim karticama (PC/SC API). Kako je pokretanje Java apleta radilo u većini standardnih dekstop pregledača (Firefox, Safari, Internet Explorer…) i na većini operativnih sistema (Windows, Apple OSX, GNU/Linux) Java apleti su mogli da se naprave jednom i da rade skoro svuda. To je dovelo do toga da skoro sva rešenja za korišćenje pametnih kartica u veb aplikacijama koriste upravo tehnologiju Java apleta. Apleti su bili korak napred u odnosu na dotadašnja rešenja koja su zahtevala Internet Explorer i uporedivu ActiveX tehnologiju. „Applets are back!“ bila je zvanična poruka 2008. programerima.

I dok su JavaScript i HTML5 od tada istisnuli i Java aplete i Flash objekte skoro svuda, kada je u pitanju povezivanje sa kriptografskim uređajima nije se pojavila zgodna alternativa Java apletima. Većinu korisnika Java apleti danas asociraju na sajtove za elektronsko bankarstvo ili sajtove veb aplikacija e-uprave, preostala mesta gde se gotovo po pravilu koriste.

Od pojave Java apleta devedesetih računarska bezbednost je postala primarni aspekt. Sada je jasno da transparentno pokretanje programa sa raznih veb stranica nije baš tako dobra ideja. Česta ažuriranja krpila su rupe u platformi, a da bi pokretanje bilo manje transparentno i moguće samo uz dozvolu korisnika, počela su da obavezno iskaču upozorenja i zahtevi za stalna ažuriranja i nove dozvole. Samo ukoliko bi programeri obavili sve kako treba, ako bi aplet bio ispravno postavljen, i na računaru bile instalirane neophodne komponente, doživljaj aktiviranja apleta bi bio prihvatljiv. Otvaranjem sajta korisnik bi pri prvom učitavanju trebalo da proveri veruje li sajtu i autorima apleta da program (aplet) neće uraditi ništa štetno i u tom slučaju omogućiti pokretanje. Ipak u praksi, zbog čestih promena u platformi, ni programeri, a ni korisnici se sa ovim nisu snalazili. Apleti su postali sinonim za traumatsko iskustvo, a uz korisnike koji ne bi znali kako da procene mogu li apletu da veruju cela tehnologija je postala bezbednosni rizik.

Većina desktop veb pregledača je i pre ove najave iz Oracla potpuno onemogućila ili značajno otežala pokretanje Java apleta. Popularnost mobilnih platformi doprinela je nestanku Java apleta, oni se tamo nikada nisu ni pojavili. Možda je postojala nada da će Oracle ponuditi rešenje za oživljavanje ove tehnologije, ali najava daje jasan putokaz - prestanite da koristite Java aplete.

Java 9 se ne očekuje pre marta 2017, a tek kasnije verzije će izbaciti podršku za aplete. Ali Java apleti već sada uopšte ne rade u Google Chromu, ne rade u novom Microsoft Edge pregledaču, niti u 64-bitnom Mozilla Firefoxu. Podrška za „običan“ Firefox ističe krajem 2016. godine. Kako Oracle ne nudi perpsektivu za tehnologiju apleta jasno je da ne treba čekati Javu 9.

Programeri pomenutih veb aplikacija sada treba da smisle rešenja koja ne koriste aplete.

Jedna alternativna su nezavisni programi koji bi se instalirali na računar ili mobilni telefon, a sa kojima bi veb aplikacija mogla da razmenjuje podatke ili kojima bi aplikacija mogla da prepusti deo funkcionalnosti. Druga alternativa je razvoj ekstenzija za svaki pregledač posebno, barem one gde je moguće ostvariti traženu funkcionalnost. Treća alternativa je da u saradnji sa proizvođačima kriptografskih uređaja HTML5 tehnologije dobiju podršku za rad sa imenovanim, unapred prisutnim kriptograskim ključevima kroz sistemske interfejse za pristup uređajima.

Nezgodno je to što za razliku od Java apleta alternative ili još uvek ne postoje ili zahtevaju više paralelnih rešenja, zavisno od pregledača i operativnog sistema pa tek korisnici najpopularnije opcije mogu da računaju na sigurnu podršku (npr. samo za Microsoft Windows i Edge). Oracle predlaže korišćenje Java Web Start tehnologije koja omogućava pokretanje jedne Java aplikacije na svim sistemima, utoliko smanjujući raznolikost ali to ne donosi podršku za mobilne platforme, sa lošijim korisničkim doživljajem čak i u odnosu na aplete.

Treba naglasiti da JavaScript ne deli nikakve sličnosti niti tehnička rešenja sa Javom. U vreme nastanka JavaScripta, programski jezik Java je već bio popularan, pa je marketing i komplikovana korporativna politika jedan od razloga za slično ime. ↩

Nove zdravstvene kartice

Fri, 22 May 2015 14:33:14 +0200

Za uvođenje novih kartica zdravstvenog osiguranja (KZO) nadležni, kažu, imaju više razloga: od onemogućavanja zloupotrebe i falsifikovanja zdravstvene isprave, do toga da KZO obezbeđuje infrastrukturu za siguran pristup servisima koje će zdravstvene ustanove moći da uspostave...
Kartica - uvod u elektronsko zdravstvo, Novosti, 21. maj 2015

Zakon o zaštiti podataka o ličnosti sa punim pravom sprečava da se medicinski podaci (karton pacijenta) čuvaju u kartici, pa će po svemu sudeći nova kartica služiti samo za identifikaciju, za šta je mogao da posluži i bilo koji drugi „dokument sa slikom“. Osim toga nova KZO u sebi ipak čuva neke nemedicinske podatke:

Glavni blokovi podataka na KZO sadrže sledeće (u zagradi nije kompletan spisak):

podaci o dokumentu (period važenja, broj dokumenta, serijski broj čipa)

nepromenjivi tekstualni podaci o vlasniku (LBO, ime, prezime, datum rođenja)

promenjivi tekstualni podaci o vlasniku (datum overe , datum važenja)

Pored ovih podataka u čipu se nalaze elektronski sertifikati vlasnika KZO, elektronski potpisi podataka, kao i sertifikati službenog lica koje je potpisalo te podatke u toku procesa izdavanja, overe ili neke druge operacije nad KZO.
Uputstvo za rad sa HCReader aplikacijom, NetSet, 20. jun 2013

Međtuim, prvo pitanje je da li su i ovi podaci mogli da se čuvaju u informacionom sistemu tako da se nakon identifikacije bilo kojim drugim dokumentom u zdravstvenoj ustanovi kroz sistem dobije ispis i podataka o osiguraniku. Podaci baš kao i do sada svakako neće biti samo u kartici, inače bi se postavilo pitanje šta se dešava kada se ona ošteti ili izgubi.

Drugo, ukoliko podaci moraju biti u kartici i ne mogu se uvek prenositi kroz informacioni sistem, na primer kako bi bili dostupni i u ustanovama koje nisu povezane u jedinstveni informacioni sistem, treba istaći da je nova lična karta sa čipom (izdata nakon avgusta 2014) moderna javacard kartica koja može da odvojeno i bezbedno čuva podatke za više razlitih aplikacija (primena). Bez većih tehničkih problema mogla je da uz funkciju lične karte, kartice za kvalifikovani e-potpis, oružanog lista ima i funkciju kao kartica zdravstvenog osiguranja. Posebna zdravstvena kartica mogla je da se izdaje samo onima koji su želeli ličnu kartu bez čipa, koji žele da poseduju odvojeni dokument, deci i drugim licima koja nemaju ličnu kartu, a imaju pravo na zdravstveno osiguranje. Šta više ista domaća kompanija obezeđuje softversku podršku i za LK sa čipom i za novu KZO.

Sve pomenute usluge koje KZO treba da navodno omogući tiču se upravo identifikacije i elektronske identifikacije, a tu nema potrebe za uvođenjem nove kartice već se može upotrebiti postojeća elektronska identifikacija: LK sa čipom kao na portalu eUprava, eID podržan kvalifikovanim el. potpisom što se već sada koristi na portalima ePorezi i CROSO, a kasnije i neki drugi postupak elektronske identifikacije koji nastane usvajanjem evropske eIDAS uredbe u domaćem zakonodstvu kroz već najavljeni novi Zakon o elektronskom poslovanju (prostija identifikacija mobilnim telefonom i drugo).

U celoj aferi sa KZO najveći je problem što su neke verovatno tehnički već zastarele kartice ranije kupljene i sada kroz naplatu personalizacije (izdavanja) treba namiriti trošak i sačuvati se od odgovornosti za promašeni projekat.

Nova kartica nije preduslov za najavljene usluge, a svakako neće biti ni magično rešenje za redove i čekanje. Najvažnije usluge - zakazivanje i elektronski recept/uput se mogu uspešno realizovati kroz jedinstveni informacioni sistem, možda i bez uslova da osiguranici koriste visok nivo elektronske identifikacije i čitač kartica na svom računaru.

Sa druge strane naizgled bez koordinacije sa telima zaduženim za elektronske usluge i eUpravu i uz sada nove afere ubrzano se nabavlja novi jedinstveni informacioni sistem u zdravstvu bez jasne relacije u odnosu na ranije korake postignute kroz veoma skupe DILS i EU-IHIS projekte. Potpuno neshvatljivo i bahato, novi informacioni sistem čak nije ni predviđen da koristi nove kartice:

Od početnog pitanja gde čuvati podatke, u kartici ili informacionom sistemu, postoji opasnost da dobijemo skupe kartice i nefunkcionalan informacioni sistem, a podaci će verovatno još dugo ostati na papiru, nedostupni kada su potrebni, a podložni „raspitivanju“ bez kontrole kada je privatnost značajna.