Përvoja e aplikimit të teknologjisë Rutoken për regjistrimin dhe autentikimin e përdoruesve në sistem (pjesa 1)

Përshëndetje! Do të doja të ndaja përvojën time mbi këtë temë.

Rutoken është një zgjidhje harduerike dhe softuerike në fushën e autentikimit, mbrojtjes së informacionit dhe nënshkrimit elektronik. Në thelb, është një USB që mund të ruajë të dhënat e autentikimit që përdoruesi i përdor për të hyrë në sistem.

Në këtë shembull, përdoret Rutoken EÇP 2.0.

Për të punuar me këtë Rutoken, është e nevojshme të instaloni një shofer në Windows..

Për Windows, instalimi i vetëm një shoferi siguron instalimin e gjithçkaje që nevojitet që sistemi operativ ta njohë Rutoken-in tuaj dhe të mund të punoni me të.

Me Rutoken-in mund të ndërveproni në mënyra të ndryshme. Mund ta aksesoni atë nga ana serverike të aplikacionit, ose direkt nga ana klientike. Në këtë shembull, do të shqyrtojmë ndërveprimin me Rutoken-in nga ana klientike të aplikacionit.

Ana klientike e aplikacionit ndërvepron me Rutoken-in përmes plugin-it të Rutoken. Kjo është një program, i cili instalohet veçmas në çdo shfletues. Për Windows, është e nevojshme thjesht të shkarkoni dhe të instaloni plugin-in, i cili ndodhet në këtë lidhje..

Tani, mund të ndërveprojmë me Rutoken-in nga ana klientike e aplikacionit.

Në këtë shembull, është trajtuar ideja e zbatimit të algoritmit të autorizimit të përdoruesit në sistem duke përdorur skemën e sfidës dhe përgjigjes.

Thelbi i ideve është si vijon:

1. Klienti dërgon një kërkesë për autorizim në server.
2. Serveri në përgjigje të kërkesës nga klienti dërgon një string të rastësishëm.
3. Klienti e plotëson këtë string me 32 bita të rastësishëm.
4. Klienti nënshkruan string-un e marrë me certifikatën e tij.
5. Klienti dërgon në server mesazhin e koduar të marrë.
6. Serveri verifikon nënshkrimin, duke marrë mesazhin origjinal të pa koduar.
7. Serveri shkëput 32 bitët e fundit nga mesazhi i pa koduar të marrë.
8. Serveri krahasohet rezultatin e marrë me atë mesazh që ishte dërguar gjatë kërkesës për autorizim.
9. Nëse mesazhet janë të njëjta, autorizimi konsiderohet i suksesshëm.

Në algoritmin e mësipërm ka një koncept të tillë siç është certifikata. Në kuadër të këtij shembulli, duhet të kuptohet një teori e caktuar kriptografike. Në Habra ka një artikull të shkëlqyer mbi këtë temë..

Në këtë shembull do të përdorim algoritme të kodimit asimetrik. Për të realizuar algoritmet asimetrik, nevojitet një çift çelësash dhe një certifikatë.

Çift çelësash përbëhet nga dy pjesë: çelësi privat dhe çelësi publik. Çelësi privat, siç e thotë emri, duhet të mbetet sekret. Ne e përdorim atë për të dekriptuar informacionin. Çelësi publik mund t'i jepet kujtdo. Ky çelës përdoret për të koduar të dhënat. Kështu, çdo përdorues mund të kodojë të dhëna duke përdorur çelësin publik, por vetëm pronari i çelësit privat mund të dekriptojë këtë informacion.

Certifikata është një dokument elektronik që përmban informacion rreth përdoruesit të cilit i përket certifikata, si dhe çelësin publik. Me certifikatën, përdoruesi mund të nënshkruajë çdo të dhënë dhe ta dërgojë atë në server, i cili mund ta verifikojë këtë nënshkrim dhe të dekriptojë të dhënat.

Për të nënshkruar saktësisht një mesazh me certifikatën, duhet ta krijojmë atë siç duhet. Për këtë, në Rutoken fillimisht krijohet një çift çelësash, dhe pastaj certifikata duhet të lidhet me çelësin publik të këtij çifti. Certifikata duhet të ketë pikërisht atë çelës publik që ndodhet në Rutoken, kjo është e rëndësishme. Nëse ne thjesht krijojmë një çift çelësash dhe certifikatën menjëherë në pjesën klient të aplikacionit, si do të mundet pastaj serveri të dekriptojë këtë mesazh të koduar? Sepse ai nuk di asgjë për çiftin e çelësave as për certifikatën.

Nëse përhapej më tepër në këtë temë, mund të gjeni informacione interesante në internet. Ekzistojnë disa qendra certifikimi, të cilave ne u besojmë paraprakisht. Këto qendra certifikimi mund të lëshojnë certifikata për përdoruesit, ato instalojnë këto certifikata në serverin e tyre. Pas kësaj, kur klienti i drejtohet këtij serveri, ai sheh pikërisht këtë certifikatë, dhe sheh se ajo është lëshuar nga një qendër certifikimi, prandaj ky server mund të besohet. Më shumë informacion mbi si të konfigurohet gjithçka saktësisht, në internet gjithashtu ka shumë. Për shembull, mund të filloni me këtë.

Nëse kthehemi në problemin tonë, zgjidhja duket e qartë. Duhet ndonjë mënyrë për të krijuar qendrën tonë të besnikërisë. Por para kësaj, duhet të kuptojmë mbi cilat baza qendra e besnikërisë duhet t'i japë një certifikatë përdoruesit, duke qenë se ajo nuk di asgjë për të. (Për shembull, emri i tij, mbiemri, etj.) Ka një gjë që quhet kërkesë për certifikatë. Më shumë mbi këtë standard mund të shihni, për shembull, në Wikipedia. ru.wikipedia.org/wiki/PKCS
Ne do të përdorim versionin 1.7 — PKCS#10.

Do të përshkruajmë algoritmin e krijimit të certifikatës në Rutoken (burimi i parë — dokumentacioni):

1. Në klient krijojmë një çift çelesh dhe e ruajmë atë në Rutoken. (ruajtja ndodh automatikisht)
2. Në klient krijojmë një kërkesë për certifikatë.
3. Nga klienti dërgojmë këtë kërkesë në server.
4. Për të marrë kërkesën për certifikatë në server, lëshojmë certifikatën nga qendra jonë e besnikërisë.
5. E dërgojmë këtë certifikatë në klient.
6. Në klient ruajmë certifikatën në Rutoken.
7. Certifikata duhet të lidhet me atë çift çelesh që u krijua në hapin e parë.

Tani bëhet e qartë se si serveri do të jetë në gjendje të dekriptojë nënshkrimin e klientit, pasi ai vetë i dha atij certifikatën.

Në pjesën tjetër do të shqyrtojmë në detaje se si të konfigurojmë qendrën tonë të besnikërisë duke u bazuar në një bibliotekë të plotë kriptografike me burim të hapur openSSL.

Burimi: habr.com