Ovo je tragedija ako je istina, iskrena da budem prestao sam da verujem nasim novinarima ali ako je stvarno tako kako si napisao to je definitivno korak u nazad a ne napred...

Pa apsolutnoj istini za volju, jedino sto za sad znam je to pozivanje na saltersku proceduru a pokusavam da dodjem do konkretnih dokaza (jedino ako ne postoji box na papirnom formularu da uneses heksadecialno kljuceve ); jedini za sada nacin je da odem i na svoju licnu kartu izvadim jedan, sto ne dolazi u obzir.
Probacu da se bar docepam formulara iz poste i da iscupam iz salterusa sta se dobije na ruke, ako uopste ista znaju. Sajt poste je naravno beskoristan (tamo jos uvek pise da su postanske uputnice novost tako da se sajt verovatno azurira jednom u deset godina), a novinari su i suvise zauzeti cestitanjem ministarki a i suvise needukovani o PKI-u da bi postavljali takva pitanja. Sve mi je to mnogo neozbiljno, ja sam ucestvovao u "izgradnji" dela koda za QuoVadis CA na Bermudama i znam kakve su sve peripetije imali i sta su sve morali da urade i fizicki oko datacentra i logisticki oko procedura i programerski oko softvera da bi svoj rootCA ubacili u windows (i time automatski bili ovlasceni izdavaci na svim Windows masinama), i pride sta sam ja kao contractor sve morao da uradim, obrazlozim i dokumentujem o kodu koji sam radio. Naspram toga ova PTT avantura mi deluje kao da je neko negde u kancelariji instalirao Microsoft Certificate Authority server i przi certove, nigde ne mozes da nadjes ni publisher policy a kamoli nesto ozbiljnije.

Član 14. pravilnika o tehničkim postupcima koje je donela Vlada:


Politika sertifikacije PTT Srbija, tacka 4 "OPERATIVNI ZAHTEVI U PROCESU IZDAVANjA SERTIFIKATA", strana 5:



Nema potrebe za ispitivanjem radnika na salteru, tu su kontakt podaci na http://www.ca.posta.rs... Ne znam na koji nacin je regulisano da privatni kljuc ne moze da napusti uredjaj ali pretpostavljam da postoji neko hardversko ogranicenje.

Da, ali sta sprecava postu da PRE stavljanja tek izgenerisanog privatnog kljuca na uredjaj stavi isti i u neku svoju bazu podataka privatnih kljuceva?

I, btw., nekidan sam se raspitivao oko SER sertifikata za web server, u smislu da ne mora korisnik na firefox-u da dodaje "exception" vec da mu se automatski https otvori i proveri ispravnost sertifikata. Receno mi je da to nije moguce sa postinim sertifikatom jer njihov CA ROOT nije u internet pretrazivacima, pa bi korisnici morali da prvo instaliraju njihov CA ROOT pa da onda dodju na npr. stranicu za logovanje na https protokolu. Posto nas takva varijanta nije interesovala, odustali smo od daljeg raspitivanja, ali mi nije prosto jasno zasto se nisu dogovorili sa entrust-om sa kojim saradjuju da za te potrebe izdaju entrust-ov sertifikat koji je odavno u svim vecim browserima.

I zanimljivo, tad adresa sajta nije bila www.ca.posta.rs vec http://www.cepp.rs/ca/default.asp koji sad daje gresku 404. Tad je bilo i mnogo vise dokumenata na stranici, i bio je i nekakav cenovnik koji je bio nesto 600, 1200 dinara za razne stvari. (link koji ne radi se sad vidi recimo na http://www.cepp.rs/servisi.asp, dok sa naslovne stranice vodi na www.ca.posta.rs).

E ovo vec lici na nesto, i dokumentacija lici na ono na sta bi trebalo. Nadam se samo da se ti pravilnici i primenjuju. Ovo ujedno i objasnjava pocetnu cenu od 6500din, zbog USB tokena koji je sam oko $50.

Mada sa tim u vezi postoji jedan problem (eh kad ne bi bilo ). Ne znam za G&D StarKey100 (mada pretpostavljam da je ista prica) ali znam sigurno da iKey 2032 ne stiti privatni kljuc od eksporta kad je poznata lozinka, niti je to moguce spreciti na tim jeftinim tokenima bez crypto cipa jer kljuc mora da predje na komp da bi potpisao hash. iKey takodje ne loguje exporte pa se ne zna koliko puta je i da li je kljuc exportovan, imam jedan iKey zakacen za privezak, Quo Vadis ga isto valja svojim klijentima (doduse prazan uz uputstvo kako da ga napunis). On ima veoma dobru zastitu od kradje privatnog kljuca ali je njegova zastita aktivna ako i samo ako sam generises key-pair i password i onda das samo javni kljuc na sertifikaciju. Ako ti CA puni token i CA odredjuje lozinku onda po definiciji najslabije karike CA ima tvoj privatni kljuc, cime se opet vracamo na mrmota.

Ovo je sasvim normalno, svi root CA-ovi prolaze kroz ovaj period, ne moze drugacije. Sad kad je CA operativan Posta mora da krene sa inicijativom da njihov rootCA udje u distribucije. Sa nekima ce lako, sa nekima ce malo teze (npr sa MSom), i taj period ume i da potraje, ali kad se zavrsi prvi sledeci Windows Update/SP/release ce imati postin root CA. Inace, po nasem zakonu oni nisu mogli da budu pod Entrustom jer onda ne bi bili rootCA, a pride bi Entrust morao da se registruje u Srbiji kao root CA i da na teritoriji srbije ispunjava sve zakonske uslove.

Hm. zar opnda ne bi mogli da budu (ako se dobro secam naziva) chained root sa entrust-om? Ako sam dobro shvatio, to znaci da oni izdaju, ali entrustov rootCA vrsi proveru ispravnosti, ili tako nesto? Posto si upuceniji u tematiku i ako znas nesto o tome mogao bi da napises... ako imas vremena.
Hvala.

Pa ono sto ti i dobijas od poste (a i da uzmes od nekog drugog isto bi dobio) je chained cert. Tj, to ne dobijas cert koji je izdao postin rootCA vec dobijas cert koji je potpisao intermediary CA, tj chained root CA, koji opet pripada posti. Kad bi posta uspostavila chained root sa Entrustom to bi znacilo da Entrust svojim imenom (a bogami i root certom) garantuje za certove koje izda posta, sto retko ko hoce da uradi za nekog drugog, naposletku Entrust stavlja svoj cert u torbu a mozda neko u posti izdaje certove ispod ruke. To je velika retkost i obicno se chained rootovi izdaju samo vecim firmama sa ogranicenim upotrebama certova za unutrasnje potrebe firme a po posebnim ugovorima. A i mislim (mrzi me da sad listam da nadjem clan) da je zakonom odredjeno da root certovi na vrhu lanaca svih certova izdatih u srbiji budu registrovani u srbiji, valjda iz prvanih razloga vestacenja na sudu.

Ako pogledas postine root certove videces da ih ima dva i da je drugi izdat od prvog. Ovo se radi najvise zbog zastite investicije, posto je kao sto smo rekli veliki pain-in-the-ass da proturis svoj root cert u masovnu upotrebu uz ogroman trud i troskove onda se privatni kljuc koji ide uz root cert cuva kao da je od suvog zlata (gram na gram verovatno vredi mnogo vise od zlata ), obicno je povelik (2048bit+) i izdaje se na veoma dug period (20, 30 i vise godina) i obicno je protokol za upotrebu privatnog kljuca tog certa veoma rigorozan i kontrolisan i iz tog razloga se koristi za jednu i samo jednu svrhu, da potpise intermediary root cert i napravi chain. Zamisli npr Entrust da kompromituje svoj root cert i da mora da ga povuce, to je problem zbog kog CA firma moze da propadne nacisto.

Intermediary cert vec nije toliko "skup" za odrzvanje i ako bas hoces mozes i da ga revokujes i izdas novi a da ne napravis veliku stetu (koji bi npr nastala ako bi morao da povuces root cert) sem sto moras ponovo svima da izdas certove ali ne moras iz pocetka da ga ubacujes u OSove, pa shodno tome mozes da ga koristis uz manje i jeftinije mere opreza u eksploataciji (koji su i dalje kontrolisani ali u manjoj meri). U principu se oni prave sa max 2048 bita i na periode od 5-10 godina, mada vidim da se posta otvorila do 2028-e, sto po meni bas i nije dobra ideja, al ajde, manje me to zulja nego bahatost sa privatnim kljucevima. E "kupcima" se izdaju certovi potpisani privatnim kljucem ovog chained ili intermediary root-a. A cela ta prica vazi iz jednog prostog razloga, poverenje se odredjuje na nivou root certa, ako verujes postinom root cert-u onda verujes SVEMU sto je iz toga proizaslo i sto dodje do tvoje masine, svi intermediary certovi, svi SSL certovi, sve email certovi, itd, itd. Svaki ispravan lanac koji potice iz root certa je tada "od poverenja". Neki CA cak imaju i dodatni layer (obicno za neke low level upotrebe), pa je lanac iz cetiri dela, mada je to retko.

Ne znam sta te jos interesuje?

OK, poslao sam email njihovoj tehnickoj podrsci:



Videcemo sta ce odgovoriti.

Ok, mala, zapravo velika ispravka.

Sad sam krenuo da busim po svom iKey-u (ionako je vreme da se produzi Thawte notary cert) i da maltretiram ortaka iz QuoVadisa i dosli smo do zakljucka da postoji cypher cip na iKey 2032 tokenu koji podrzava hardversko SHA-1 potpisivanje, pored generatora 2048bit RSA/DSA kljuceva (doduse ne mogu da komentarisem kvalitet tog generatora), samim tim postoji opcija blokade exporta privatnog kljuca cime je kljuc trajno vezan za token i ne moze se reprodukovati. Sam hardver tokena ima sve sto je neophodno za digitalno potpisivanje (mada je za SHA-1 nadjen collision, al ajde da ne trazim dlaku u jajetu posto je i sa tom rupom jos uvek dovoljno dobar).
Ovo zapravo menja celu moju pricu i ovim ponuda PTTa izgleda veoma pristojno i dostojno jednog CA-a. Jos samo da neko izvadi cert i potvrdi da je blokiran export za private key pa da priznam da se i kod nas desilo nesto pozitivno i ozbiljno Ja bih izvadio al mi se ne daju pare za nesto sto vec imam za dzabe.

izvinjavam se, greskom obrisah sopstvenu poruku....

Samo sam cekao da se sam ispravis :). Nisi dobro procitao pratece pravilnike ili ti malo one skracenice raznoraznih standarda unose zabunu. Naime poodavno se kod ozbiljnijih CA koristi hardver koji je po FIPS standardu tj. sa kojeg nije moguce exportovati private key. Takodje koriste se uredjaji na kojima se generise private key i koji nikada ne napusta usb token ili smart card. Ukoliko se koristi HSM sa instaliranim Key Recovery managerom kriptovani delovi privatnih kljuceva ostaju na sistemu, ali se oni mogu dekriptovati samo u HSM-u koji je i sam po FIPS standardu i tako je moguce uraditi key recovery.

Ne bune mene nikakve skracenice, niti sumnjam u objavljene pravilnike (mada ih iskreno nisam procitao do kraja jer mi je bilo mucno da sve prevodim nazad u engleski jer ocigledno prilicno nevest prevod nekog Entrustovog CPSa), niti iskreno verujem nekoj domacoj instanci da verifikuje da li posta CA primenjuje u praksi svoje sopstevene pravilnike. Kad budem dobio postin CA u spisku zvanicnih medjunarodnih CA-ova preko OS update-a znacu da je neko ozbiljan bio da proveri dal se to primenjuje. Tad ce verovatno morati da se okaci i CPS na engleskom pa cu se lakse snaci sa citanjem istog. (BTW, ako ti radis za postin CA, linkovi za Word i PDF CPS-a su izmesani). Moja inicijalna rekacija je ocigledno bila knee-jerk reakcija na nepotpuno izvestavanje B92 i na sakrivenost zvanicnog sajta CA-a, i ja cu uvek da priznam svoju gresku, medjutim cela ova prica nije jos dovedena do kraja.

I nema potrebe da se frljamo nepotpunim skracenicama, FIPS ima 4 nivoa i ok, da sam procitao ceo CPS video bih da implementirate FIPS Level 2 za krajnje korisnike (sto sam i pretpostavljao zbog iKey-a). Medjutim FIPS 2 nije ono sto mene intersuje, to je jednostavno standard po kome se radi specificni hardver (ukljucjuci HSM i tokene) tako da se ne moze "na silu" doci do privatnih kljuceva korisnika, sto je ok, lepo je to znati ako mi neko ukrade token, medjutim FIPS i dalje ne sprecava sam CA da zadrzi kopiju privatnog kljuca kad se punjenje tokena radi od strane CA, dal rucno ili preko specijalnog HSM-a svejedno je, narocito ako je HSM generisao kljuceve i ako je HSM povezan za trusted system cime si i dalje unutar FIPS-3 a mozes da skladistis kljuceve . Ono sto sasvim dobro znam iz teorije i prakse PKI-a je da je sistem prati princip najslabije karike i da sve ostale odlicno odradjene stvari padaju u vodu ako jedna karika ne valja, a ako CA poseduje privatni kljuc korisnika ili ima bilo kakvu mogucnost da do tog privatnog kljuca dodje, makar on bio kriptovan u HSMu, to predstavlja slabu kariku jer vise nista ne zavisi od CPSa i pouzdanosti hadvera i softvera i od toga koji je FIPS level, vec zavisi od toga koliko su zaposleni u CA skloni zloupotrebi i koja je njihova "cena".

Dok god postoji key-recovery mehanizam za privatni kljuc korisnika (a po tvom postu ocigledno postoji) postoji i mogucnost zloputrebe, mozda nije tako jednostavan da cistacica moze da ga mazne "iz fioke", samo smo individualni zlocin zamenili sa zaverom (ako je potrebno n od m ljudi da odradi key-recovery) sto je nazalost koncept koji nije toliko stran u ovoj zemlji. Teorija zavere ili ne, CA mora da bude iznad svega ovoga i ako moze kriticki da se postavi pitanje poverenja u CA onda to poverenje ne postoji. Postin i bilo koji drugi CA nema nikakvog razloga da bude bilo gde blizu privatnog kljuca korisnika jer isti ne ucestvuje ni na koji nacin u procesu sertifikacije, samo moze da se obije posti o glavu.

Nema potrebe da se zestis ;). Nisam mislio da te zaslepljujem skracenicama nego nisam hteo da bunim ljude koji mozda citaju ovo, a koje tema ne interesuje u tolikoj meri. Inace nisam siguran da li posta ima mehanizam za key recovery (ne radim tamo - daleko bilo), ali pravilnik je strog i u slucaju neke zloupotrebe prilicna odsteta bi mogla da ih zadesi ukoliko dodje do neke zloupotrebe tako da ne verujem da bi neko rizikovao zbog mog ili tvog potpisa. Cinjenica je da je postin CA bio potreban Srbiji. Ovo je samo prvi korak u celoj prici vezanoj za elektronsko poslovanje i sl.

Ma ne zestim se, nego ne volim kad se nesto zamagljuje upotrebom skracenica i buzzwords-a. I ne bi bilo nista lose u tome da radis za njih, narocito ako se taj CA vodi kako bi trebalo, sta vise bilo bi dobro kad bi neko od njih obratio paznju na ovu temu da bi se eventualno resile te decije bolesti jer je to najvise u njihovom interesu. Meni ni iz dzepa ni u dzep, ja cu reci kako jeste i ako mi ne odgovara uvek mogu da uzmem cert od nekog drugog ili da se potpisem olovkom kao do sada.

I slazem se sa tim sto pricas, ali dok god kompletna procedura kako oni kazu "ceremonije generisanja kljuceva" i baratanja tudjim privatnim kljucevima nije dokumentovana u sitna crevca i zatim overena od strane externog audita koji nema sukob interesa, postojace bojazan postojanja duplikata privatnog kljuca i samim tim problem kasnije na sudu oko poricanja i bice dovoljno da se pojavi samo jedan jedini cert ciji privatni kljuc je kompromitovala posta i da to zakopa ceo CA, a to im apsolutno ne treba.
A inace sad videh u glavi 3.3 da postin CA ne dozvoljava key-recovery sto je dobro, znaci da nemaju povoda za skladistenje privatnih kljuceva. Sad je samo ostalo da nas ubede da se privatni kljucevi zaista generisu u skladu sa tim pravilnikom i da su tokeni koje valjaju non-exportable. To je sve, i ako to uspeju prevazisli smo najveci i najkriticniji problem, jedan token = jedan privatni kljuc i tek onda vazi moje priznanje . Ono sto ostaje posle toga su sledeci manje kriticni problemi:

- sigurnost generisane lozinke. CPS ne govori nista o tome i ne zna se kako se tacno generise lozinka i ko moze da sebi da obezbedi pristup toj lozinci, u krajnjoj instanci zaposleni u CA moze da gurne parce papira izmedju glave matricnog stampaca i maskirne indigo koverte i da dobije odstampanu lozinku. Dok god token ne stigne u ruke korisniku svako sa loznkom moze da generise potpise. Po CPSu nigde se ne belezi trenutak fizickog preuzimanja tokena tako da korisnik ne moze da porekne potpise nastale izmedju trenutka generisanja kljuca i preuzimanja tokena.

- Period vazenja Posta CA1 intermediary certa od 20 godina, sto je previse. Ne zato sto ce neko brute force da provali kljuc za manje od 20 godina vec zbog revocation liste. Za dvadeset godina ce se nakupiti previse revoke-ova, a nista nije ucinjeno da se taj problem transfera CRL-a resi (verovatno zato sto ga jos nisu imali). Ne samo da revocation nije podeljen na bazni i delta, pa ce svaka provera ispocetka morati da ucita CELOKUPAN revocation list, vec se stavise revocation lista drzi vezana za glavni root CA, sto znaci da ce se i pri proveri validnosti intermediary sertiifkata morati ucitati puna CRL lista, sto je iskreno van mozga. Ovo je stvarno odradjeno bezveze, ali nije kriticno za sigurnost, vise je smetnja za admine i bice smenja za korisnike kasnije pri proveri potpisa, i u principu moze da se resi pustanjem sledeceg intermediary certa sa bolje resenim CRL mehanizmom.

- Period vazenja licnih certova od 5 godina vezanih za tokene. Ako sad trazis token dobices ga 2009-e, a kroz pet godina ce biti 2014, a SHA-1 ubrzano stari i relativno skoro ce biti zamenjen sa SHA-2 u masovnoj upotrebi dok ce tokeni i dalje ostati vezani za SHA-1 i svejedno ce morati da se nabavljaju novi. Mozda je ovo ucinjeno zbog produzenja perioda eksploatacije tokena jer se izgleda po CPSu nakon isteka certa isti baca, ali je generalno losa praksa, non-repudiation certovi ne bi trebalo da traju duze od godinu dana, kako zbog napredka tehnologije, tako i iz sledeceg razloga

- pouzdanost identifikacije. Posto se ocigledno identifikacija svodi na licno ubedjenje salteruse da je osoba koja predaje zahtev ujedno i osoba iz licne karte. Problem koji posotji nije do Poste CA vec do toga da je nase stare obrasce licne karte veoma lako falsifikovati (ima po crnim hronikama horor prica o prodavanju tudjih stanova laznim licnim kartama i slicno) tako da efektivno identifikacija moze da slaze i osoba A moze doci do certa koji glasi na osobu B. Resenje bi bilo da se identifikacini dokument ogranici na nove licne karte i nove pasose koje je dosta teze falsifikovati. U principu bi ovo bila kriticna stvar ali ce proci neko vreme pre nego digitalni potpisi udju u praksu a to tad cemo se valjda resiti starih licnih karti, jedino ce ostati problem sa prevarantima koji sad uzmu lazne tokene dok jos mogu, pa imaju punih 5 godina da ih iskoriste

OK, odgovorise mi na onaj mail, prvog sledeceg radnog dana (pohvalno):



Ako sam dobro razumeo mail certove ce izdavati kroz web interfejs, a one "kvalifikovane" za ugovore samo na tokenima. Ok, sa njihovog stanovista to razumem (pod uslovom da je token non-exportable), time se oni osiguravaju od zloupotreba korisnika posto se soft-cert moze duplikovati po zelji, samo sto jos uvek fali onaj deo gde su korisnici zasticeni od zloupotrebe poste.
Jedino sad nije jasno koji ce biti proces identifikacije korisnika za web cert kad je licna karta uslov za kvalifikovani, ali ko sto rekose bice objavljeno . Poslao sam im poziv da se pridruze ovoj temi i da razjasne neke stvari, nadam se da ce prihvatiti.