YetAnotherForum
Добродошли Нађи | Активне теме | Пријава | Региструјте се

4 Страна123>»
[Tag as favorite]
MUP CA
forumadmin
#1 Послато : Wednesday, September 01, 2010 4:10:37 PM
Ранг: Administration

[Medals:]

Групе:
Присружио се: 3/14/2010
Поруке: 2

[Thanks: 0 times]
[Was thanked: 0 time(s) in 0 post(s)]
Preneto sa sa b92 bloga Gorana Vučkovića Pa što se niko ne hvali?!


grakic
Цитирај:
eDocSigner je (nepotrebna) Windows aplikacija, a midlver (drajveri za karticu) su dostupni samo za Windows.

Ukratko fali ili PKCS#11 modul za Linux (ili u izvornom kodu) koji bi mogao da se zalepi na PC/SC interfejs ili puni ISO7816 drajver i PKCS#15 emulator za pametnu karticu za OpenSC. Sam PKI i podrška za potpis u programima OpenOffice.org, Evolution, Firefox pod GNU/Linuksom nije problem i dobija se automatski. Ostaje međutim pitanje da li bi takav midlver i podrška u programima ispunjavali Tehničko-tehnološke uslove za sredstva za kvalifikovani potpis. Upravo iz tog razloga, naša CA tela ne oslanjaju se na podršku koja postoji u drugim programima već nude neke svoje alate kao što je eDocSigner koji ima glupa ograničenja, na primer da ne dozvoljava da dve osobe potpišu dokument.


ubuntu-LoCo
Цитирај:

Ukoliko neko može da pomogne značilo bi nam. Goran je pisao eDocSigner-u nema odgovora.
Ovo ograničenje da dve osobe ne mogu da potpišu jedan dokument ozbiljno bogalji celu stvar, ali sve u svemu

SUPER ŠTO JE KRENULO!


vucko
Цитирај:

Za gledaoce sa jeftinijim kartama: Goran je inače Goran Rakić, twitter: http://twitter.com/grakic i on je druga dobra vest, koju sam zaboravio da pomenem, izvinjavam se: Čitač elektronske lične karte za GNU/Linuks

Inače Word pravi korektne potpise ličnom katom, već progonim svoje bankare da mi prihvate neko ovlašćenje potpisano ličnom kartom na word dokumentu (ili selim depozit čim stignem u Srbiju).

@ubuntu-LoCo
Uzgred, baš u vezi višestrukog potpisivanja, pre neki dan sam malo krenuo da se igram ovim. Znam da "obožavaš" M$, ali vidi ovaj primer. Ali višestruko potpisivanje (ugrađen potpis) bi trebalo da postoji i kod stvari tipa PDF i Word, zar ne (iskreno, nisam probao, pa nisam siguran)?


ivan@RZII
Цитирај:

Što se tiče podrške za Linux, najbolje bi bilo povezati kolege sa Upravom za informacione tehnologije MUPa koja je i nadležna za njihove sertifikate ca.mup.gov.rs. Načinjeni su neki koraci od trenutka kada je Goran publikovao FreeSteel, ne bih ništa obećao, ali nadam se da neće biti problema da se dođe do specifikacije.


vucko
Цитирај:

Hvala. Ja se do duše nisam usrećio sa podrškom za Vistu, a povremeno proveravam i ne vidim da su se verzije postavljene za preuzimanje promenile (do sada nisu). Da li ste vi u Zavodu imali iskustva sa Vistom i middleware za ličnu kartu slučajno?


ivan@RZII
Цитирај:

Testiran je middleware za ličnu kartu i na visti i na win7 i definitivno postojeća verzija 1.0.5 ne radi kako bi trebalo. Čelik se bez problema instalira i očitava podatke. Ovaj problem i još neke detalje smo prosledili MUPu, te se nadamo da će ga u dogledno vreme rešiti.


vucko
Цитирај:

Ja nekako uspeh sinoć da instaliram middleware na visti - preskočio sam instaliranje CSP (ono puca sa "nema dovoljno prostora" ) i instalirao direktno mw - i prođe, i radi (reinstalirao sam i eDocSigner posle toga, do duše).

Nego sad ne mogu da se logujem karticom na eUpravu, javlja neispravan sertifikat, a istovremeno kod mene SDC Manager (onaj MUP-ov alat koji verifikuje potpise na SDC fajlovima) prijavljuje da nema pristup CRL (prijavio sam preko one stranice za prijavu problema) - jeste li to namestili da kad je CRL servis dole, niko ne može da se loguje?


ivan@RZII
Цитирај:

Dakle ipak nešto radi. Pretpostavljam da se lični sertifikat učitao i pravilno povezao u putanji? Što se tiče prijave, da li se možda prikazala strana nema sertifikata?

Za komunikaciju Portala i CRL servisa u ovom trenutku nemam odgovor.


vucko
Цитирај:

A evo i šta je - Acrobat Reader 9 je prijavio smislenije od eDocSigner-a:



Stao sat policajcima :P
vucko
#2 Послато : Wednesday, September 01, 2010 6:14:30 PM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
Evo juče je MUP CRL servis počeo da radi i login je proradio i na vašem sajtu. Izgleda da bajata CRL lista sprečava login.

Pitanje je da li je ovo najlogičnije ponašanje sistema, bar za login - da praktično imate downtime svih usluga koje zavise od logina ličnom kartom, kada se MUP CRL servis zaglupi...
Dragan
#3 Послато : Friday, September 03, 2010 10:50:13 AM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
Juče sam sa kolegom iz RZII testirao autentifikaciju na Portal eUprave i elektronsko potpisivanje PDF zahteva, sa Internet Explorer-om i Firefox-om, sa sertifikatima sva 3 akreditovana CA. Što se tiče MUP sertifikata, rezultat na Windows XP je sledeći:

1. Internet Explorer 8: Kao rezultat elektronske transakcije koja uključuje elektronsko potpisivanje, dobija se Zahtev koji je PDF dokument koji je elektronski potpisan. Potpis tog PDF zahteva MUP sertifikatom je neispravan, što može da se vidi kada se taj dokument otvori u Acrobat Reader-u 9.3:

Error during signature verification.
Error encountered while validating:
Error encountered while BER decoding:


2. Firefox 3.6: Potpisivanje je nemoguće, jer dolazi do Crash-a Firefox-a.

Zanimljivo: Prilikom importa MUP CA sertifikata u Firefox, moguće je cekirati sve 3 opcije:

Trust this CA to identify web sites.
Trust this CA to identify email users.
Trust this CA to identify software developers.

međutim, na importovanom CA sertifikatu nisu čekirane te 3 opcije, što može da se vidi kada se izabere CA sertifikat i pritisne dugme Edit. Ako se tada čekiraju sve 3 opcije i pritisne dugme OK, ništa se ne događa. To ponašanje je krajnje neobično.

Ne isključujem mogućnost da smo nešto kod testa pogrešili, tako da sam pozvao sva 3 CA na zajednički Workshop.

Sa PTT sertifikatima PDF zahtevi su uspešno potpisani i kada je korišćen IE, i kada je korišćen Firefox.

Dragan, PTT
vucko
#4 Послато : Friday, September 03, 2010 3:13:48 PM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
Dragan је написао:
Potpis tog PDF zahteva MUP sertifikatom je neispravan, što može da se vidi kada se taj dokument otvori u Acrobat Reader-u 9.3:

Error during signature verification.
Error encountered while validating:
Error encountered while BER decoding:

Ja imam isti problem kad potpisujem koristeći rumunski novaPDF softver za kreiranje PDF dokumenataa - odštampam nešto u novaPDF printer podešen da potpisuje dokumente, unesem lozinku za karticu itd - dobije se dokument gde se potpis vidi, ali pri verifikaciji prsne sa istim ovim problemom.

Za sada sumnjam na jednu od dve stvari: ili onaj problem što je Goran Rakić objavio na svom blogu sa BER kodiranjem root sertifikata (vodeće nule), ili nešto što se tiče UTF i ćirilice u common name.
Dragan
#5 Послато : Friday, September 03, 2010 3:26:29 PM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
Ćirilica u CN sigurno nije problem, jer u PKS sertifikatima je latinica, pa je ista greska:

Error during signature verification.
Error encountered while validating:
Error encountered while BER decoding:
Ivan@RZII
#6 Послато : Friday, September 03, 2010 5:09:04 PM
Ранг: Administration

[Medals:]

Групе: Registered
Присружио се: 8/26/2010
Поруке: 2
Локација: Beograd

[Thanks: 3 times]
[Was thanked: 0 time(s) in 0 post(s)]


vucko је написао:
Evo juče je MUP CRL servis počeo da radi i login je proradio i na vašem sajtu. Izgleda da bajata CRL lista sprečava login.

Pitanje je da li je ovo najlogičnije ponašanje sistema, bar za login - da praktično imate downtime svih usluga koje zavise od logina ličnom kartom, kada se MUP CRL servis zaglupi...


Na osnovu MUPCAGradjani.crl vidim da je u tom periodu lista izdata 24 08 2010 u 09:57h a sledeća 25 08 2010 u 19:54h što je vremenski period duži od 24h. Pretpostavljam da je lifetime liste 24h i da je nekih 10sati lista bila bajata i da ste baš u tom periodu probali login na Portal.

Mislim da problem nije u logici ponašanja sistema, obzirom da validnost sertifikata zavisi od liste. Ne možemo nekome verovati, iako teret dokazivanja nije na njemu nego na CA.

U svakom slučaju postoji problem, te će CRL servis će biti jedna od tema pri sledećem susretu sa MUP CA.




vucko
#7 Послато : Friday, September 03, 2010 5:22:23 PM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
Ivan@RZII је написао:

Na osnovu MUPCAGradjani.crl vidim da je u tom periodu lista izdata 24 08 2010 u 09:57h a sledeća 25 08 2010 u 19:54h što je vremenski period duži od 24h. Pretpostavljam da je lifetime liste 24h i da je nekih 10sati lista bila bajata i da ste baš u tom periodu probali login na Portal.

Mislim da je problem malo komplikovaniji, jer ja sam nekoliko dana (3-4) uzastopce probao ovo - i svaki put je prijavljivalo problem. Ja sam na mom blogu komentar sa ovim stavio 27. septembra u 16:17, a to je bilo nekoliko minuta pošto sam napravio sliku ovog prozora. Znači tada je već bilo preko dva dana od trenutka isteka važnosti CRL. A onda još par dana nije radilo.
vucko
#8 Послато : Wednesday, September 08, 2010 1:20:51 PM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
Dragan је написао:
Ćirilica u CN sigurno nije problem, jer u PKS sertifikatima je latinica, pa je ista greska:

Error during signature verification.
Error encountered while validating:
Error encountered while BER decoding:

Ovo je kanda greška ili u iTextSharp biblioteci ili u sertifikatu (ono što je Goran Rakić primetio) ili u Acrobat Readeru - evo ja imam sad jednu malu aplikaciju sa XMLSig i jednu sa iTextSharp - i XMLSig se uredno validira, dok PDF sa potpisom puca u Acrobat Reader-u na ovaj isti način - BER dekodiranje (ok i daje mi neki default vidljivi potpis ali to ću da iskonfigurišem kad stignem).

Ako je serijski broj u sertifikatima izvor ovoga, to može da bude ozbiljan problem, jer to znači, čini mi se, da morau da se izdaju novi CA sertifikati i reinicijalizuju sve kartice. Ako je iTextSharp - to možemo da zakrpimo u sorsu, možda...
Dragan
#9 Послато : Wednesday, September 08, 2010 4:04:12 PM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
Preporučujem ti da kupiš PTT kvalifikovani sertifikat, i nećes imati problema.
vucko
#10 Послато : Wednesday, September 08, 2010 4:48:29 PM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
Dragan је написао:
Preporučujem ti da kupiš PTT kvalifikovani sertifikat, i nećes imati problema.

Hvala na ponudi :) ali ovde su vam možda mušterije ekipa iz Uprave za informatiku MUP (ili NetSet), za konsultacije - ja ću videću da li može nešto da se uradi sa iTextSharp - ali pre svega da dovršim ovu moju igračka-aplikaciju...
grakic
#11 Послато : Thursday, September 09, 2010 11:21:10 PM
Ранг: Newbie

[Medals:]

Групе: Registered
Присружио се: 8/26/2010
Поруке: 8
Локација: Београд

[Thanks: 3 times]
[Was thanked: 0 time(s) in 0 post(s)]
Ko želi da radi validaciju MUP CA korenskih sertifikata u OpenSSL biblioteci (ili programima koji je koriste) može da iskoristi zakrpljenu verziju sa https://launchpad.net/~g...ic/+archive/serbian-eid

Koliko mi je poznato Microsoft CryptoAPI i Mozilla NSS ne rade reinterpretiranje X.509 sertifikata pri prostoj validaciji pa bi ova funkcija trebalo da radi ispravno u svim programima koji koriste ove biblioteke.

Podržavam savet za korišćenje Poštinih sertifikata iako lično nisam korisnik usluge pa ne mogu da primerom potvrdim ili osporim jesu li serijski brojevi izdatih sertifikata proizvoljan višebajtni niz (četiri u slučaju korenskih) ili su saglasni sa standardom i predstavljaju kodiran pozitivni ceo broj.

Ja sam o mogućem problemu upoznao Dragoslava Stanižana u MUP CA i Zorana Savića u NetSet Globalu, verujem da će se, ako zapravo postoji neki problem do CA, to efikasno rešiti.

Цитирај:

Format serijskog broja sertifikata definisan je u RFC 3280[1] na koji
se poziva i Pravilnik o bližim uslovima za izdavanje kval. el.
sertifikata.

Stav 4.1.2.2 RFC dokumenta određuje serijski broj kao pozitivan ceo
broj. Kodiranje zapisa opisano je u ITU-T X.690 dokumentu[2] u DER
formatu. DER format određuje predstavljanje u TLV formatu gde je prvi
bajt oznaka tipa (za ceo broj 02), pa bajt sa dužinom i zatim toliko
bajtova sa podacima.

[1] http://tools.ietf.org/html/rfc3280
[2] http://www.itu.int/ITU-T...anguages/X.690-0207.pdf

Sami podaci predstavljeni su u BER kodiranju i to poštujući princip
minimalne dužine zapisa. BER kodiranje celih brojeva (poglavlje 8
dokumenta) kaže da se broj predstavlja u komplementu dvojke, tako da
bitovi prvog bajta i vodeći bit drugog bajta ne budu svi 0 ili ne budu
svi 1. Ovo osigurava da ne dođe do prekoračenja, a da broj bude
predstavljen najmanjim brojem bajtova.

Korenski sertifikat za serijski broj ima zapis (heksadecimalno):

02 04 00 00 00 64

Dok bi po standardu trebalo da bude (0x64 = 0b 0110 0100):

02 01 64

Kada programi i biblioteke koji poštuju standard rekodiraju serijski
broj sertifikata (interpretiraju ga kao ceo broj, dekadno 100, i potom
kodiraju u odgovarajućem formatu) zapis se promeni i izračunati SHA1
otisak se ne podudara.

Kako se otisak ne podudara, validacija ne prolazi.

OpenSSL radi upravo to.
vucko
#12 Послато : Friday, September 10, 2010 4:50:52 AM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
grakic је написао:
Koliko mi je poznato Microsoft CryptoAPI i Mozilla NSS ne rade reinterpretiranje X.509 sertifikata pri prostoj validaciji pa bi ova funkcija trebalo da radi ispravno u svim programima koji koriste ove biblioteke.

Mukica je što jednu sitnicu izgleda rade, a ona zezne i CryptoAPI.

Radi se o sledećem: u RFC 2630, definiciji PKCS-7, postoji polje SignerIdentifier u strukturi SignerInfo koja se pojavljuje kao vektor na kraju strukture SignedData (ASN definicije iz RFC 2630):

RFC 2630 је написао:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }

SignerInfos ::= SET OF SignerInfo

SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }


E ovaj issuerAndSerialNumber predstavlja izdavaoca sertifikata ključa kojim je potpisan dokument i serijski broj sertifikata.

Sa druge strane, na ovom URL možete pronaći sors kod Crypt32 biblioteke, a u njemu sledeću C funkciju:

Crypt32 је написао:
static BOOL CDecodeSignedMsg_VerifySignature(CDecodeMsg *msg, PCERT_INFO info)
{
BOOL ret = FALSE;
DWORD i;

for (i = 0; !ret && i < msg->u.signed_data.info->cSignerInfo; i++)
{
ret = CertCompareCertificateName(X509_ASN_ENCODING,
&msg->u.signed_data.info->rgSignerInfo\[i\].Issuer, &info->Issuer);
if (ret)
{
ret = CertCompareIntegerBlob(
&msg->u.signed_data.info->rgSignerInfo\[i\].SerialNumber,
&info->SerialNumber);
if (ret)
break;
}
}
if (ret)
ret = CDecodeSignedMsg_VerifySignatureWithKey(msg, 0, i,
&info->SubjectPublicKeyInfo);
else
SetLastError(CRYPT_E_SIGNER_NOT_FOUND);

return ret;
}

Tu ćete primetiti da se poredi izdavalac i serijski broj.

Na žalost, pri formiranju CMS, CryptoAPI izvadi iz sertifikata serijski broj i pravilno (a drugačije) ga enkodira, a onda kada upoređuje serijski broj iz sertifikata i iz SignerInfo.SignerIdentifier, poredi ih u BER formi. Serijski broj moje lične karte heksadekadno je 11 7a 27 i u sertifikatu je kodiran kao 02 04 00 11 7a 27 a u SignerIdentifier polju je 02 03 11 7a 27 - nije me mrzelo da u dibageru prođem kilobajt ipo heksadekadnih cifara da ovo proverim.

Manifestacija ovoga svega je da za moj sertifikat CryptoAPI prsne pri validaciji potpisane poruke, jer izgleda poredi BER reprezentacije serijskog broja, a one nisu iste (kao što se gore vidi), pa baci grešku CRYPT_E_SIGNER_NOT_FOUND. Dekodiranje sertifikata izgleda saplete Adobe Acrobat - u njemu se sertifikati mogu uredno gledati, jer ih verovatno windows tada dekodira - ali očigledno, kada su u CMS, to sve ljosne.

Sve u svemu, prvih oko 17 miliona serijskih brojeva (256*256*256) su problematični - posle će da radi super...

Imam utisak da ću morati još jednom u policiju, kad dođem u Bgd sledeći put - za novi sertifikat :(((((((

Imenjače, molim te prenesi ovo Zoranu i Dragoslavu (Zorana pozdravi, znamo se još iz vremena kad je bio u IPME).
Dragan
#13 Послато : Monday, September 13, 2010 3:53:15 PM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
RFC 3280 zamenjen je sa RFC 5280 u maju 2008.

5280 Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson,
S. Farrell, S. Boeyen, R. Housley, W. Polk. May 2008. (Format:
TXT=352580 bytes) (Obsoletes RFC3280, RFC4325, RFC4630) (Status:
PROPOSED STANDARD)
grakic
#14 Послато : Monday, September 13, 2010 4:10:08 PM
Ранг: Newbie

[Medals:]

Групе: Registered
Присружио се: 8/26/2010
Поруке: 8
Локација: Београд

[Thanks: 3 times]
[Was thanked: 0 time(s) in 0 post(s)]
Korisno zapažanje. Odeljak "4.1.2.2. Serial Number" je neizmenjen. U važećem pravilniku MTID o uslovima za izdavanje kvalifikovanih el. sertifikata stoji obaveza saglasnosti sa starijim dokumentom.
Dragan
#15 Послато : Tuesday, September 14, 2010 8:23:51 AM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
Evo još jednog zapažanja:

Pravilnik o izdavanju vremenskog žiga ("Sl. glasnik RS", br. 112/2009 od 30/12/2009):

Za formiranje elektronskog potpisa iz stava 2. ovog člana koristi se jedan od sledećih kriptografskih algoritama:
1) RSA (Rivest Shamir Adleman) primenom standarda PKCS#1 i uz minimalnu dužinu RSA modulusa "n" od 2048 bita;
...


Posle toga se donosi i usvaja nova verzija (12/03/2010):


Pravilnik o tehničko-tehnološkim postupcima za formiranje kvalifikovanog elektronskog potpisa i kriterijumima koje treba da ispune sredstva za formiranje kvalifikovanog elektronskog potpisa ("Sl. glasnik RS", br. 13/2010 od 12/03/2010), i u njemu ostaje:

1. RFC 3280

2. Kvalifikovani elektronski potpis formira se primenom jednog od standardizovanih asimetričnih kriptografskih algoritama, i to:
1) RSA (Rivest Shamir Adleman) primenom standarda PKCS#1 uz minimalnu dužinu RSA modulusa n od 1024 bita;

A koliko puta sam pisanim putem i usmenim putem rekao na Radnoj grupi i na konferencijama da je objavljen RFC 5280, a da je ključ RSA-1024 bita veoma male dužine za 2010. godinu. Pema nemačkom Pravilniku od 17.12.2007., za kraj 2007. godine ključ RSA-1024 je minimum, a RSA-2048 recommended; a za kraj 2010. godine ključ RSA-1728 je minimum, a RSA-2048 recommended.
Dragan
#16 Послато : Wednesday, September 15, 2010 11:40:17 AM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
Pored kratkog RSA ključa od 1024 bita, sa security aspekta najveći potencijalni problem je u konceptu da se prvi par ključeva korisnika (javni i tajni/privatni) čuvaju u okviru MUP-a. Izvod iz CPS:


CPS – Certificate Practice Statement (http://ca.mup.gov.rs/MUPCACPS.pdf):

4.12.1 Politika i praksa čuvanja i rekonstrukcije privatnog ključa
...
Prvi par ključeva i prvi sertifikat služe za autentikaciju korisnika i za šifrovanje dokumenata putem procedure digitalne envelope za datog korisnika.

U cilju omogućavanja dešifrovanja dokumenata šifrovanih za datog korisnika u incidentnim slučajevima, kao i za eventualne službene potrebe, neophodno je da se dati privatni ključ čuva u okviru MUP-a na zaštićen način (šifrovan) u odgovarajućoj bazi.
...
7.1.2 Ekstenzije u sertifikatu

Kvalifikovani sertifikat za autentikaciju/šifrovanje

Ekstenzija korišćenja ključa: Digital Signature, Key Encipherement, Data Encipherement


Propusti u navedenom konceptu su sledeći:

1. Navedeni "Kvalifikovani sertifikat za autentikaciju/šifrovanje" ima polje (ekstenziju) "Key Usage=Digital Signature, Key Encipherment". S obzirom na to da sadrži "Digital Signature" to znači da pripadajući tajni (privatni) ključ može da se koristi za elektronsko potpisivanje (npr. Microsoft Office, Adobe Acrobat,...). Problem je u tome što taj tajni ključ ne postoji samo u čipu lične karte, već se čuva i u MUP-u (videti CPS). Znači, najvažnija funkcija e-potpisa ne može da se ispuni, a to je neporecivost. Nezabeležen je primer u praksi da sertifikaciono telo čuva kod sebe tajni ključ korisnika koji može da se koristi za potpisivanje. A ono što dodatno komplikuje ceo sličaj, je da korisnici koji imaju ličnu kartu sa čipom, po automatizmu dobijaju, bez njihovog zahteva, taj prvi par ključeva (velika većina nije ni svesna toga).

2. S obzirom na to da pomenuti sertifikat sadrži i "Key Encipherment", to znači da pomenuti par ključeva može da se koristi za šifrovanje i dešifrovanje. Ali zašto bi neko vršio šifrovanje tim ključem, kada zna da sem njega, dešifrovanje može da uradi u MUP (CPS: U cilju omogućavanja dešifrovanja dokumenata šifrovanih za datog korisnika u incidentnim slučajevima, kao i za eventualne službene potrebe, neophodno je da se dati privatni ključ čuva u okviru MUP-a na zaštićen način (šifrovan) u odgovarajućoj bazi).
Teško je naći primer u svetu da javno sertifikaciono telo čuva kod sebe tajni ključ korisnika koji može da se koristi za dešifrovanje. To je koncept internih sertifikata u okviru kompanija, gde vlasnik ili direktor želi da njegovi zaposleni šifrovano komuniciraju, a da on može da pročita njihovu šifrovanu komunikaciju, naročito u slučaju prestanka radnog odnosa zaposlenog.

3. Tzv. "Kvalifikovani sertifikat za autentikaciju/šifrovanje" ne može da bude kvalifikovani ako je namenjen šifrovanju tj. ako sadrži "Key Encipherment". Kvalifikovani sertifikat može da sadrži u polju Key Usage samo "Non-Repudiation" i/ili "Digital Signature". To je objasnjeno u dokumentu ETSI TS 102 280 V1.1.1 (2004-03) "X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons", poglavlje 5.4.3 Key usage:

If the certificate is declared to be a Qualified Certificate according to TS 101 862 [5] then the key usage setting SHALL be limited to type A, B or C.

Znači, iz tzv. "Kvalifikovanog sertifikat za autentikaciju/šifrovanje", treba ukloniti polje "QC (Qualified Certificate) statement".

Kod belgijskih ID kartica postoji koncept 2 para ključeva, a najvažnije karakteristike 2 sertifikata su sledeće:

1. Kvalifikovani sertifikat:
Key Usage: Non-repudiation
sadrži polje QC (Qualified Certificate) statement

2. Sertifikat za autentifikaciju:
Key Usage: Digital Signature
nema polje QC (Qualified Certificate) statement

I naravno, tajni (privatni) ključevi korisnika postoje samo na ID kartici, i nigde više.
vucko
#17 Послато : Wednesday, September 15, 2010 12:42:00 PM

Ранг: Member

[Medals:]

Групе: Registered
Присружио се: 8/25/2010
Поруке: 22
Локација: Glazgov

[Thanks: 5 times]
[Was thanked: 1 time(s) in 1 post(s)]
Dragan је написао:
Pored kratkog RSA ključa od 1024 bita, sa security aspekta najveći potencijalni problem je u konceptu da se prvi par ključeva korisnika (javni i tajni/privatni) čuvaju u okviru MUP-a. Izvod iz CPS:


CPS – Certificate Practice Statement (http://ca.mup.gov.rs/MUPCACPS.pdf):

4.12.1 Politika i praksa čuvanja i rekonstrukcije privatnog ključa
...
Prvi par ključeva i prvi sertifikat služe za autentikaciju korisnika i za šifrovanje dokumenata putem procedure digitalne envelope za datog korisnika.

U cilju omogućavanja dešifrovanja dokumenata šifrovanih za datog korisnika u incidentnim slučajevima, kao i za eventualne službene potrebe, neophodno je da se dati privatni ključ čuva u okviru MUP-a na zaštićen način (šifrovan) u odgovarajućoj bazi.
...
7.1.2 Ekstenzije u sertifikatu

Kvalifikovani sertifikat za autentikaciju/šifrovanje

Ekstenzija korišćenja ključa: Digital Signature, Key Encipherement, Data Encipherement


Propusti u navedenom konceptu su sledeći:

1. Navedeni "Kvalifikovani sertifikat za autentikaciju/šifrovanje" ima polje (ekstenziju) "Key Usage=Digital Signature, Key Encipherment". S obzirom na to da sadrži "Digital Signature" to znači da pripadajući tajni (privatni) ključ može da se koristi za elektronsko potpisivanje (npr. Microsoft Office, Adobe Acrobat,...). Problem je u tome što taj tajni ključ ne postoji samo u čipu lične karte, već se čuva i u MUP-u (videti CPS). Znači, najvažnija funkcija e-potpisa ne može da se ispuni, a to je neporecivost. Nezabeležen je primer u praksi da sertifikaciono telo čuva kod sebe tajni ključ korisnika koji može da se koristi za potpisivanje. A ono što dodatno komplikuje ceo sličaj, je da korisnici koji imaju ličnu kartu sa čipom, po automatizmu dobijaju, bez njihovog zahteva, taj prvi par ključeva (velika većina nije ni svesna toga).

2. S obzirom na to da pomenuti sertifikat sadrži i "Key Encipherment", to znači da pomenuti par ključeva može da se koristi za šifrovanje i dešifrovanje. Ali zašto bi neko vršio šifrovanje tim ključem, kada zna da sem njega, dešifrovanje može da uradi u MUP (CPS: U cilju omogućavanja dešifrovanja dokumenata šifrovanih za datog korisnika u incidentnim slučajevima, kao i za eventualne službene potrebe, neophodno je da se dati privatni ključ čuva u okviru MUP-a na zaštićen način (šifrovan) u odgovarajućoj bazi).
Teško je naći primer u svetu da javno sertifikaciono telo čuva kod sebe tajni ključ korisnika koji može da se koristi za dešifrovanje. To je koncept internih sertifikata u okviru kompanija, gde vlasnik ili direktor želi da njegovi zaposleni šifrovano komuniciraju, a da on može da pročita njihovu šifrovanu komunikaciju, naročito u slučaju prestanka radnog odnosa zaposlenog.

3. Tzv. "Kvalifikovani sertifikat za autentikaciju/šifrovanje" ne može da bude kvalifikovani ako je namenjen šifrovanju tj. ako sadrži "Key Encipherment". Kvalifikovani sertifikat može da sadrži u polju Key Usage samo "Non-Repudiation" i/ili "Digital Signature". To je objasnjeno u dokumentu ETSI TS 102 280 V1.1.1 (2004-03) "X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons", poglavlje 5.4.3 Key usage:

If the certificate is declared to be a Qualified Certificate according to TS 101 862 [5] then the key usage setting SHALL be limited to type A, B or C.

Znači, iz tzv. "Kvalifikovanog sertifikat za autentikaciju/šifrovanje", treba ukloniti polje "QC (Qualified Certificate) statement".

Kod belgijskih ID kartica postoji koncept 2 para ključeva, a najvažnije karakteristike 2 sertifikata su sledeće:

1. Kvalifikovani sertifikat:
Key Usage: Non-repudiation
sadrži polje QC (Qualified Certificate) statement

2. Sertifikat za autentifikaciju:
Key Usage: Digital Signature
nema polje QC (Qualified Certificate) statement

I naravno, tajni (privatni) ključevi korisnika postoje samo na ID kartici, i nigde više.

Ovde je više pitanje zašto su oba sertifikata nazvali isto (common name) - to stvara nepotrebnu konfuziju.

Inače "key escrow" šema za ključeve za šifrovanje ne bi trebalo da bude nešto značajno novo. Pitanje je koliko je jednostavno uzeti ključ iz escrow-a - da li je to nešto što se radi kad kom bude volja ili je smislen protokol na bazi sudskog naloga.

Inače ja sam primetio ovaj problem sa imenovanjem, pa zahvatam, u ovoj igrački koju pravim, ključ koji ima X509KeyUsageFlags.NonRepudiation - to ima samo "drugi" ključ, namenjen za kvalifikovani potpis.

Uzgred - da li neko zna slučajno - da li je moguće koristiti 2048-bitne ključeve (tj. više od 1024 bita) sa tekućim ličnim kartama (hardver, operativni sistem na čipu), ili bi MUP morao da naruči drugu plastiku (tj. čip)?

Takođe - 1024-bitni ključevi u ličnim kartama nisu loš marketinški detalj za vaš novi servis za timestamping :-)
Dragan
#18 Послато : Wednesday, September 15, 2010 1:02:29 PM
Ранг: Advanced Member

[Medals:]

Групе: Registered
Присружио се: 9/3/2010
Поруке: 32
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 9 time(s) in 7 post(s)]
[Vucko] Ovde je više pitanje zašto su oba sertifikata nazvali isto (common name) - to stvara nepotrebnu konfuziju.

To su ispravili kod PKS, kada su videli sta su uradili kod MUP-a.
grakic
#19 Послато : Monday, September 27, 2010 4:24:29 AM
Ранг: Newbie

[Medals:]

Групе: Registered
Присружио се: 8/26/2010
Поруке: 8
Локација: Београд

[Thanks: 3 times]
[Was thanked: 0 time(s) in 0 post(s)]
Kada već pominjemo belgijsku eID, evo kako izgleda javno objavljen dokument sa tehničkom specifikacijom apleta/interfejsa na pametnoj kartici http://eid.belgium.be/nl...PPL_EN_tcm147-22452.pdf

Tu je i mogućnost poručivanja testnih ličnih karata uz zadavanje proizvoljne konfiguracije (istekla, povučena,...) po povoljnoj ceni http://www.eid-shop.be/ dok je izvorni kod midlvera javno dostupan na http://code.google.com/p/eid-mw/

Postoji i dokumentacija za programere aplikativnog softvera http://eid.belgium.be/nl..._Guide_tcm147-63130.pdf kao i otvoreno rešenje za veb http://code.google.com/p/eid-applet/
Matarese
#20 Послато : Wednesday, June 15, 2011 2:49:26 PM
Ранг: Newbie

[Medals:]

Групе: Registered
Присружио се: 6/15/2011
Поруке: 1
Локација: Beograd

[Thanks: 0 times]
[Was thanked: 0 time(s) in 0 post(s)]
forumadmin је написао:

grakic
Цитирај:
eDocSigner je (nepotrebna) Windows aplikacija, a midlver (drajveri za karticu) su dostupni samo za Windows.



Ja sam instalirao middleware na W7 bez problema ali kada ubacim karticu - krene instalacija koja se završi obaveštenjem da nije uspelo - nisu pronađeni drajveri...
Zna li neko šta dalje?
Корисници који тренутно читају ову тему
Guest (2)
4 Страна123>»
[Tag as favorite]
Скочи на форум  
Ви не можете [/ b] писати нове теме у овом форуму.
Ви не можете [/ b] одговарати на теме у овом форуму.
Ви не можете [/ b] брисати ваше поруке у овом форуму.
Ви не можете [/ b] мењати ваше поруке у овом форуму.
Ви не можете [/ b] креирати анкете у овом форуму.
Ви не можете гласати у анкетама у овом форуму.

SoClean Theme By Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 RC1 | YAF © 2003-2009, Yet Another Forum.NET
Ова страница је креирана у N3 секунди.