Kriptografija: PKI

November 27, 2019 | SECURITY | No Comments

Infrastruktura javnog ključa se obično naziva PKI (eng. Public Key Infrastructure) i predstavlja termin koji se koristi za opisivanje zakona, politika, procedura, standarda i softvera koji regulišu i kontrolišu sigurne razmjene informacija zasnovane na temelju kriptografije javnog ključa (PKC).

Naredna tabela sadrži osnovne PKI komponente:

KomponentaOpis
Digital CertificatesTemelj PKI, to su elektronski kredencijali koji se sastoje od javnih ključeva.
Certification Authority (CA)Izdaje digitalne certifikate korisnicima ili podređenim CA-ima.
Registration Authority (RA)Prihvata zahtjeve za novim certifikatima, osigurava autentičnost podnositelja zahtjeva i dovršava postupak registracije za CA.
Validation Authority (VA) Pruža uslugu za provjeru valjanosti digitalnog certifikata.
Certificate Policy and Practice StatementsDokumenti koji opisuju kako se CA i njegovi certifikati koriste, stepen povjerenja, pravne obaveze ako je povjerenje narušeno i tako dalje.
Certificate RepositoriesSkup servisa ili lokacija na kojima se certifikati pohranjuju i objavljuju.
Certificate Revocation Lists (CRL)Lista certifikata koji su ukinuti prije navedenog roka isteka.

Svrha ove infrastrukture je upravljanje ključevima i digitalnim certifikatima koji se koriste za kriptovanje i digitalno potpisivanje. U kriptografiji je PKI ugovor koji povezuje javne ključeve sa njihovim identitetima korisnika preko tijela za certificiranje (CA).

Sada da ovo sve pojednostavimo maksimalno, pretpostavićemo da Alice i Bob koriste asimeričnu kriptografiju za komunikaciju. Svako od njih ima par ključeva, jedan privatni i jedan javni. Problem nastaje kada oni objave javne ključeve, kako će Alice znati da je baš ovo javni ključ od Boba i obrnuto. Ovaj problem riješava PKI pomoću CA tijela, ono će potvrditi da je taj javni ključ stvarno od Boba pomoću digitalno potpisanog certifikata. Analogno kao što policajac provjerava identitet preko lične karte koju je izdao nadležni organ, tako se može provjeriti i javni ključ preko certifikata koji je izdao CA.

Kako dobiti digitalni certifikat?

Bob mora prvo generisati par ključeva (ukoliko ih nema), zatim pravi zahtjev za certifikat. Taj zahtjev je obično jedan fajl sa ektenzijom .csr (Certificate Signing Request). Tu popunjava neke svoje osnovne podatke (ime, grad, državu, mail…) i naravno tu je i njegov javni ključ. Neću u detalje ulaziti o strukturi CSR-a, koga zanima moze pogledati Wiki: CSR. Sada ovaj zahtjev potpisuje sa svojim privatnim ključem i šalje CA, tačnije RA. RA možemo zamisliti kao dio CA koji provjerava zahtjeve, potpis zahtjeva provjeri pomoću javnog ključa Boba, možda ga čak i kontaktira. U glavnom kada zahtjev prođe provjeru CA izdaje Bobu digitalni certifikat, fajl po X.509 standardu sa ekstenzijom .cer ili .crt koji dokazuje vlasništvo nad javnim ključem. Bravo Bob!

Kako provjeriti digitalni certifikat?

Tijelo za certificiranje (CA) je entitet od povjerenja koji obavlja izdavanje certifikata, potvrđuje identitet vlasnika certifikata (RA) i pruža dokaz da je certifikat validan (VA). VA kao dio CA pruža uslugu za provjeru valjanosti digitalnog certifikata preko lista za opoziv certifikata (eng. Certificate Revocation List) ili kratko CRL. CA generiše CRL kao fajl sa extenzijom .crl i predaje ga VA. Obično se ponudi download ovih lista preko OCSP protokola.
Ako Alice hoće glumi policajca i provjeri da li je Bobov certifikat dobar prvo će pogledati datum isteka certifikata ako je on dobar obratiće se VA. Preko njihovog servisa poslati certifikat ili ako nemaju servis preuzeti CRL i pogledati ima li tu Bobov certifikat. I stvarno Bobov certifikat se nasao na CRL uz razlog keyCompromise, što znači da je neko doša u posjed Bobovog privatnog ključa. 🙊
Mogući razlozi za opoziv su definisani u RFC 5280 s69.

Zašto postoje RA i VA kad to sve može CA raditi?

Zamislite neko dođe do privatnog kljuca od CA, svi certifikati koje je taj CA izdao više nisu validni. Iz tog razloga obično je CA offline i na mrežu se spaja samo za potpisivanje certifikata i generisanje CRL. U teoriji bi trebala postojati struktura sa tri nivoa CA tijela. Obično jedan Root CA čiji certifikat važi najduže i koji se čuvaju izvan mreže na vrlo sigurnoj lokaciji, Policy CA-ovi koji nisu u jednom domenu a čuvaju se izvan mreže i Issuing CA-ovi koji izdaju certifikate korisnicima i njihov certifikat po pravilu bi trebao da važi duplo duže od certifikata koje izdaju korisniku. Znači Root CA izdaje certifikate za Policy CA, oni izdaju certifikate za Issuing CA, a Issuing CA-ovi onda izdaju certifikate krajnjim korisnicima. U ovom slučaju kao na slici gdje njihov certifikat važi 5 godina, certifikat koji bi izdali korisniku će važiti 2 godine.

Šta je Certificate Chain?

Lanac certifikata (eng. Certificate Chain) predstavlja listu certifikata, od ROOT certifikata do certifikata krajnjeg korisnika. Da bi se certifikatu krajnjeg korisnika moglo vjerovati, taj certifikat mora izdati CA koji je uključen u trusted store sistema ili uređaja gdje se certifikat koristi. Ako certifikat nije izdao pouzdan CA, tada će se provjeriti da li je certifikat od narednog CA u lancu pouzdan i tako dalje (uz lanac) sve dok se ne nađe pouzdan CA.

Šta je sad Trusted Store?

Trusted Store ili TrustStore sadrži certifikate drugih strana ili od CA-ova kojima sistem vjeruje. Windows ima svoj, Firefox ima svoj, moguće ga je otvoriti i gledati certifikate. U suštini skoro svaki sajt ima svoj certifikat. Kada se otvori google.ba, Firefox (ili neki drugi web browser) dobije njegov certifikat i počinje provjeravati lanac dok ne nađe certifikat koji ima u svom TrustStore-u. Ako pronađe takav certifikat dobijete mali katanac 🔒 lijevo pored adrese ili zeleno https. Na slici lijevo je lanac certifikata od google.ba, a desno Trusted Store Root certifikati od Chroma.

Kako napraviti PKI?

Osnova PKI-a je Root CA, tako da je potrebno prvo napraviti Root CA. Ovo će možda zvučiti previše jenostavno, ali bukvano:

  1. Generišete par RSA ključeva (privatni i javni)
    openssl genrsa -out rootCA.key 4096
  2. Kreirate zahtjev za certifikat (CSR)
    openssl req -new -key rootCA.key -out rootCA.csr
  3. Potpišete zahtjev sa privatnim ključem
    openssl x509 -req -days 365 -in rootCA.csr -signkey rootCA.key -out rootCA.crt

To je to, upravo ste kreirali interni CA sa samopotpisanim certifikatom. Interni, jer se ne nalalazi ni u jednom Trusted Store-u, pa mu je primjena ograničena. Sve zavisi od toga za šta i kako planirate koristiti taj PKI. Pravi certifikat (potpisan od Root CA koji se već nalazi u Trusted Store-ima) se može kupiti od Let’s Encrypt, DigiCert, GlobalSign… Postoje i besplatna (Open Sorce) riješenja za CA tijela kao što je EJBCA.

Link Certifikat

Kada CA prelazi sa starog para ključeva na novi, pored novog samopotpisanog certifikata, CA treba izdati certifikat koji sadrži stari javni ključ potpisan novim privatnim ključem i certifikat koji sadrži novi javni ključ potpisan starim privatnim ključem (link certifikat). Oba ova certifikata su samo-izdani, ali nisu samo-potpisani, mehanizam poznat kao Cross Certification. Istek CA ključa je problem jer što se tiče klijenata to je potpuno novi CA. Link certifikat ovo riješava tako što će klijentima reći da ovaj novi certifikat zamjenjuje onaj istekli koji je u njihovom Trust Store-u. Kako oni vjeruju starome, a stari je potpisao ovaj novi, mogu da vjeruju i novom samopotpisanom certifikatu.

Trusted Timestamping

Kratko i jasno ovo je udaranje vremenskog žiga (eng. timestamp) na digitalni dokument. Podrazumijeva sigurno praćenje vremena stvaranja i izmjene dokumenta, tako da ni vlasnik dokumenta nije u mogućnosti da ga promijeni. Da bi vremenska oznaka bila pouzdana mora je izdati Time Stamping Authority ili kratko TSA. Jedno novo CA tijelo koje heš dokumenta i vremanski žig digitalno potpisuje pomoću svoga privatnog ključa. Nadam se da nije potrebno detaljnije objašnjavati ove slike jer je sve već poznato iz prethodnih postova. Više informacija o ovome je moguće pronaći u RFC 3136.

Izrada vremenske oznake
Provjera

, , , ,

About Author

Leave a Reply

Your email address will not be published. Required fields are marked *