Iskustvo u korišćenju Rutoken tehnologije za registraciju i autorizaciju korisnika u sistemu (1. deo)

Dobar dan Želim podijeliti svoje iskustvo na ovu temu.

Rutoken je hardversko i softversko rješenje u oblasti autentifikacije, sigurnosti informacija i elektronskog potpisa. U suštini, ovo je fleš disk koji može pohraniti podatke o autentifikaciji koje korisnik koristi za prijavu na sistem.

U ovom primjeru se koristi Rutoken EDS 2.0.

Za rad sa ovim Rutokenom potreban vam je instaliraj drajver na windows.

Za Windows, instaliranje samo jednog drajvera osigurava da je sve što je potrebno instalirano tako da OS vidi vaš Rutoken i može raditi s njim.

Možete komunicirati sa Rutokenom na različite načine. Možete mu pristupiti sa serverske strane aplikacije ili direktno sa strane klijenta. Ovaj primjer će pogledati interakciju s Rutokenom sa strane klijenta aplikacije.

Klijentski dio aplikacije stupa u interakciju sa rutokenom preko rutoken dodatka. Ovo je program koji se zasebno instalira na svaki pretraživač. Za Windows samo trebate preuzeti i instalirati dodatak, nalazi se na ovom linku.

To je to, sada možemo komunicirati sa Rutokenom sa strane klijenta aplikacije.

Ovaj primjer govori o ideji implementacije algoritma autorizacije korisnika u sustav koristeći shemu izazov-odgovor.

Suština ideje je sledeća:

1. Klijent šalje zahtjev za autorizaciju serveru.
2. Server odgovara na zahtjev klijenta slanjem nasumičnih stringova.
3. Klijent popunjava ovaj niz nasumičnih 32 bita.
4. Klijent potpisuje primljeni niz svojim certifikatom.
5. Klijent šalje primljenu šifrovanu poruku serveru.
6. Server provjerava potpis primanjem originalne nešifrirane poruke.
7. Server uklanja posljednja 32 bita iz primljene nešifrirane poruke.
8. Server upoređuje primljeni rezultat sa porukom koja je poslana prilikom zahtjeva za autorizaciju.
9. Ako su poruke iste, onda se autorizacija smatra uspješnom.

U gornjem algoritmu postoji takva stvar kao što je certifikat. Za ovaj primjer, morate razumjeti neku kriptografsku teoriju. Na Habréu postoji odličan članak na ovu temu.

U ovom primjeru koristit ćemo algoritme asimetrične enkripcije. Da biste implementirali asimetrične algoritme, morate imati par ključeva i certifikat.

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

Sertifikat je elektronski dokument koji sadrži podatke o korisniku koji posjeduje certifikat, kao i javni ključ. Sertifikatom korisnik može potpisati bilo koji podatak i poslati ga serveru koji može provjeriti potpis i dešifrirati podatke.

Da biste ispravno potpisali poruku certifikatom, potrebno je da je ispravno kreirate. Da biste to uradili, prvo se kreira par ključeva na Rutokenu, a zatim sertifikat mora biti povezan sa javnim ključem ovog para ključeva. Certifikat mora imati upravo onaj javni ključ koji se nalazi na Rutokenu, ovo je važno. Ako jednostavno kreiramo par ključeva i certifikat odmah na strani klijenta aplikacije, kako onda server može dešifrirati ovu šifriranu poruku? Na kraju krajeva, on ne zna ništa ni o paru ključeva ni o certifikatu.

Ako dublje zaronite u ovu temu, možete pronaći zanimljive informacije na internetu. Postoje određeni autoriteti za sertifikaciju kojima očito vjerujemo. Ova tijela za izdavanje certifikata mogu izdavati certifikate korisnicima; oni instaliraju te certifikate na svoj server. Nakon toga, kada klijent pristupi ovom serveru, vidi upravo ovaj certifikat, i vidi da ga je izdao certifikacijski autoritet, što znači da se ovom serveru može vjerovati. Na internetu također postoji mnogo informacija o tome kako sve ispravno postaviti. Na primjer, možete početi s ovim.

Ako se vratimo na naš problem, rješenje se čini očiglednim. Morate nekako stvoriti svoj vlastiti certifikacijski centar. Ali prije toga morate shvatiti na osnovu čega bi certifikacijski centar trebao izdati certifikat korisniku, jer on o tome ne zna ništa. (Na primjer, njegovo ime, prezime, itd.) Postoji nešto što se zove zahtjev za certifikatom. Više informacija o ovom standardu možete pronaći, na primjer, na Wikipediji ru.wikipedia.org/wiki/PKCS
Koristićemo verziju 1.7 - PKCS#10.

Hajde da opišemo algoritam za generisanje sertifikata na Rutokenu (originalni izvor: dokumentaciju):

1. Na klijentu kreiramo par ključeva i spremamo ga na Rutoken. (snimanje se dešava automatski)
2. Na klijentu kreiramo zahtjev za certifikatom.
3. Od klijenta šaljemo ovaj zahtjev serveru.
4. Kada primimo zahtjev za certifikat na serveru, izdajemo certifikat od našeg certifikacijskog tijela.
5. Ovaj sertifikat šaljemo klijentu.
6. Rutoken sertifikat čuvamo na klijentu.
7. Certifikat mora biti vezan za par ključeva koji je kreiran u prvom koraku.

Sada postaje jasno kako će server moći dešifrirati potpis klijenta, budući da mu je sam izdao certifikat.

U sljedećem dijelu ćemo detaljnije pogledati kako postaviti vaše ovlaštenje za certifikate na osnovu punopravne open-source biblioteke kriptografije openSSL.

izvor: www.habr.com