Iskustvo u korištenju Rutoken tehnologije za registraciju i autorizaciju korisnika u sustavu (1. dio)

Dobar dan Želim podijeliti svoje iskustvo o ovoj temi.

Rutoken je hardversko i softversko rješenje u području autentifikacije, informacijske sigurnosti i elektroničkog potpisa. U biti, ovo je flash pogon koji može pohraniti podatke za provjeru autentičnosti koje korisnik koristi za prijavu u sustav.

U ovom primjeru koristi se Rutoken EDS 2.0.

Za rad s ovim Rutokenom trebate instalirati drajver na windows.

Za Windows, instaliranje samo jednog upravljačkog programa osigurava instaliranje svega što je potrebno kako bi OS vidio vaš Rutoken i mogao raditi s njim.

S Rutokenom možete komunicirati na razne načine. Možete mu pristupiti s poslužiteljske strane aplikacije ili izravno s klijentske strane. Ovaj primjer će promatrati interakciju s Rutokenom s klijentske strane aplikacije.

Klijentski dio aplikacije komunicira s rutokenom putem rutoken dodatka. Ovo je program koji se zasebno instalira na svaki preglednik. Za Windows samo trebate preuzeti i instalirati dodatak, nalazi se na ovoj poveznici.

To je to, sada možemo komunicirati s Rutokenom s klijentske strane aplikacije.

Ovaj primjer raspravlja o ideji implementacije algoritma autorizacije korisnika u sustavu pomoću sheme izazov-odgovor.

Suština ideje je sljedeća:

1. Klijent poslužitelju šalje zahtjev za autorizaciju.
2. Poslužitelj odgovara na zahtjev klijenta slanjem nasumičnog niza.
3. Klijent dopunjuje ovaj niz s nasumičnih 32 bita.
4. Klijent potpisuje primljeni niz svojim certifikatom.
5. Klijent šalje primljenu šifriranu poruku poslužitelju.
6. Poslužitelj provjerava potpis primanjem originalne nešifrirane poruke.
7. Poslužitelj uklanja zadnja 32 bita iz primljene nešifrirane poruke.
8. Poslužitelj uspoređuje primljeni rezultat s porukom koja je poslana prilikom zahtjeva za autorizaciju.
9. Ako su poruke iste, autorizacija se smatra uspješnom.

U gornjem algoritmu postoji nešto poput certifikata. Za ovaj primjer morate razumjeti neke kriptografske teorije. Na Habréu postoji odličan članak na ovu temu.

U ovom primjeru koristit ćemo algoritme asimetrične enkripcije. Za implementaciju asimetričnih algoritama morate imati par ključeva i certifikat.

Par ključeva sastoji se od dva dijela: privatnog ključa i javnog ključa. Privatni ključ, kao što mu ime kaže, mora biti tajan. Koristimo ga za dešifriranje informacija. Javni ključ može se podijeliti bilo kome. Ovaj ključ se koristi za šifriranje podataka. Dakle, svaki korisnik može šifrirati podatke pomoću javnog ključa, ali samo vlasnik privatnog ključa može dešifrirati te informacije.

Certifikat je elektronički dokument koji sadrži podatke o korisniku koji posjeduje certifikat, kao i javni ključ. Certifikatom korisnik može potpisati bilo koji podatak i poslati ga poslužitelju koji može provjeriti potpis i dekriptirati podatke.

Kako biste ispravno potpisali poruku s certifikatom, morate ga ispravno kreirati. Da biste to učinili, prvo se kreira par ključeva na Rutokenu, a zatim se certifikat mora povezati s javnim ključem tog para ključeva. Certifikat mora imati točno onaj javni ključ koji se nalazi na Rutokenu, ovo je važno. Ako jednostavno kreiramo par ključeva i certifikat odmah na klijentskoj strani aplikacije, kako onda poslužitelj može dekriptirati ovu šifriranu poruku? Uostalom, on ne zna baš ništa ni o paru ključeva ni o certifikatu.

Ako dublje zaronite u ovu temu, na internetu možete pronaći zanimljive informacije. Postoje određena tijela za izdavanje certifikata kojima očito vjerujemo. Ova tijela za izdavanje certifikata mogu izdavati certifikate korisnicima; oni te certifikate instaliraju na svoj poslužitelj. Nakon toga, kada klijent pristupi ovom poslužitelju, on vidi upravo taj certifikat i vidi da ga je izdalo certifikacijsko tijelo, što znači da se ovom poslužitelju može vjerovati. Na internetu ima i dosta informacija o tome kako sve ispravno postaviti. Na primjer, možete početi s ovim.

Vratimo li se našem problemu, rješenje se čini očiglednim. Morate nekako stvoriti vlastiti certifikacijski centar. No, prije toga treba smisliti na temelju čega certifikacijski centar treba korisniku izdati certifikat, jer on o tome ne zna ništa. (Na primjer, njegovo ime, prezime, itd.) Postoji takva stvar koja se zove zahtjev za potvrdu. Više informacija o ovom standardu možete pronaći, primjerice, na Wikipediji ru.wikipedia.org/wiki/PKCS
Koristit ćemo verziju 1.7 - PKCS#10.

Opišimo algoritam za generiranje certifikata na Rutokenu (izvorni izvor: dokumentaciju):

1. Stvaramo par ključeva na klijentu i spremamo ga na Rutoken. (spremanje se događa automatski)
2. Na klijentu kreiramo zahtjev za certifikatom.
3. Od klijenta šaljemo ovaj zahtjev poslužitelju.
4. Kada primimo zahtjev za certifikat na poslužitelju, izdajemo certifikat od našeg certifikacijskog tijela.
5. Ovu potvrdu šaljemo klijentu.
6. Spremamo Rutoken certifikat na klijenta.
7. Certifikat mora biti vezan na par ključeva koji je kreiran u prvom koraku.

Sada postaje jasno kako će poslužitelj moći dešifrirati klijentov potpis, budući da mu je sam izdao certifikat.

U sljedećem ćemo dijelu pobliže pogledati kako postaviti svoj autoritet za izdavanje certifikata na temelju potpune open-source kriptografske biblioteke openSSL.

Izvor: www.habr.com