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

Përshëndetje! Dua të ndaj përvojën time mbi këtë temë.

Rutoken është 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 EDS 2.0.

Për të punuar me këtë Rutoken, është e nevojshme të instaloni driver-in në Windows.

Për Windows, instalimi i një driver-i të vetëm siguron gjithçka që nevojitet që OS të njohë Rutoken-in tuaj dhe të mund të punoni me të.

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

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

Tani, tani tani, tani tani tani tani tani tani tani tani tani tani. Tani tani tani tani tani.

Në këtë shembull shqyrtohet ideja e implementimit të algoritmit të autorizimit të përdoruesit në sistem duke përdorur skemën e sfidës dhe përgjigjes.

Thelbi i kësaj ideje është:

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ë varg të rastësishëm.
3. Klienti e plotëson këtë varg me 32 bites të rastësishëm.
4. Klienti nënshkruan vargun e marrë me certifikatën e tij.
5. Klienti dërgon në server mesazhin e koduar të marrë.
6. Serveri kontrollon nënshkrimin, duke marrë mesazhin origjinal të pakoduara.
7. Serveri ndan 32 bitët e fundit nga mesazhi i pakoduara të marrë.
8. Serveri krahasohet rezultatin e marrë me mesazhin që u dërgua gjatë kërkesës për autorizim.
9. Nëse mesazhet janë të njëjta, atëherë autorizimi konsiderohet i suksesshëm.

Në algoritmin e mësipërm ekziston një koncept i tillë si certifikata. Në kuadër të këtij shembulli, është e nevojshme të kuptohet një teori të caktuar kriptografike. Në Habrë ka një artikull të shkëlqyer në këtë temë.

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

Çifti i çelësave përbëhet nga dy pjesë: çelësi privat dhe çelësi publik. Çelësi privat, siç sugjeron emri i tij, duhet të mbetet sekret. Ne e përdorim atë për të dekriptuar informacionin. Çelësi publik mund të ndahet me këdo. Ky çelës përdoret për të kriptuar të dhënat. Kështu, çdo përdorues mund të kriptojë të dhënat 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, i cili e zotëron certifikatën, si dhe çelësi publik. Me një certifikatë, përdoruesi mund të nënshkruajë çdo të dhënë dhe t'i dërgojë ato në server, i cili mund të 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 krijoni atë siç duhet. Fillimisht krijohet një çift çelësh në Ruutoken, dhe pastaj certifikata duhet të lidhet me çelësin publik të këtij çifti. Certifikata duhet të ketë saktësisht atë çelës publik që ndodhet në Ruutoken, kjo është e rëndësishme. Nëse thjesht krijojmë një çift çelësh dhe certifikatën menjëherë në anën e klientit të aplikacionit, si do të jetë në gjendje serveri të dekriptojë këtë mesazh të koduar? Ai nuk dinte asgjë për çiftin e çelësave, as për certifikatën.

Nëse zhytmi më thellë në këtë temë, mund të gjejmë informacione interesante në internet. Ekzistojnë disa qendra verifikimi, të cilave u besojmë. Këto qendra verifikimi mund të lëshojnë certifikata për përdoruesit, të cilat i instalohet në serverin e tyre. Pas kësaj, kur klienti i drejtohet këtij serveri, ai sheh këtë certifikatë dhe e sheh se është lëshuar nga një qendër verifikimi, pra mund t'i besohet këtij serveri. Më shumë informacion mbi mënyrën se si të gjitha këto duhet të konfigurohen, ka gjithashtu shumë në internet. Për shembull, mund të filloni me këtë.

Nëse kthehemi te detyra jonë, zgjidhja duket e qartë. Ne duhet në njëfarë mënyre të krijojmë qendrën tonë të besueshmërisë. Por para kësaj, duhet të kuptojmë se në bazë të cilave informacione qendra e besueshmërisë duhet të lëshojë një certifikatë për përdoruesin, pasi ajo nuk di asgjë për të (për shembull, emri, mbiemri, etj.). Ka një gjë të tillë që quhet kërkesë për certifikatë. Më shumë për 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ë — dokumentacija):

1. Në klient krijojmë një çift çelësash 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. Kur të marrim kërkesën për certifikatë në server, lëshojmë certifikatën nga qendra jonë e besueshmërisë.
5. Dërgojmë këtë certifikatë në klient.
6. Në klient ruajmë certifikatën në Rutoken.
7. Certifikata duhet të lidhet me atë çift çelësash që u krijua në hapin e parë.

Tani është e qartë se si serveri mund të dekriptojë nënshkrimin e klientit, pasi ai vetë i ka lëshuar atij certifikatën.

Në pjesën e ardhshme, do të shqyrtojmë me hollësi se si të konfigurojmë qendrën tonë të certifikimit duke përdorur një bibliotekë kriptografike të plotë me burim të hapur openSSL.

Burimi: habr.com