Ruutokeni tehnoloogia rakendamise kogemus kasutajate registreerimiseks ja autentimiseks süsteemis (osa 1)

Tere päevast! Soovin jagada oma kogemust selle teema osas.

Rутокен on riist- ja tarkvaralahendused autentimise, teabe kaitse ja digiallkirjastamise valdkonnas. Sisuliselt on see selline mälupulk, mis suudab salvestada autentimisandmeid, mida kasutaja võib kasutada süsteemi sisenemiseks.

Antud näites kasutatakse Rутокен EЦП 2.0.

Selle Rутокeni kasutamiseks on vajalik draiveri paigaldamine Windows'i süsteemi..

Windows'i puhul tagab ainult draiveri paigaldamine kõik vajaliku, et operatsioonisüsteem tuvastaks teie Rутокени ja sellega töötamine oleks võimalik.

Rутокeni saab kasutada erinevate meetoditega. Sellele võib ligi pääseda rakenduse serveripoolsest osast või otse kliendipoolsest. Antud näites vaatleme Rутокeni kasutamist rakenduse kliendipoolsest osast.

Rakenduse kliendipool suhtleb Rутокeni kaudu Rутокeni pistikprogrammi. See on programm, mis tuleb igasse brauserisse eraldi installida. Windows'i puhul tuleb pistikprogramm lihtsalt alla laadida ja installida, mis asub sellel lingil.

Nüüd saame Rутокeni kasutada rakenduse kliendipoolsest osast.

Antud näites vaatleme ideed, kuidas rakendada kasutaja autentimise algoritmi süsteemis, kasutades väljakutse-vastus skeemi.

Idee olemus on järgmine:

  1. Klient saadab autentimissoovi serverisse.
  2. Server saadab kliendi päringule vastuseks juhusliku stringi.
  3. Klient täiendab seda stringi juhuslike 32 bitidega.
  4. Klient allkirjastab saadud stringi oma sertifikaadiga.
  5. Klient saadab serverile saadud kooditud sõnumi.
  6. Server kontrollib allkirja, saades algse dekodeerimata sõnumi.
  7. Server eemaldab saadetud dekodeerimata sõnumist viimased 32 bitti.
  8. Server võrdleb saadud tulemust sellega sõnumiga, mis saadeti autentimissoovis.
  9. Kui sõnumid on samad, loetakse autentimine edukaks.

Ülaltoodud algoritmis on mõisted nagu sertifikaat. Antud näite raames tuleb mõista teatud krüptograafilist teooriat. Habré on olemas suurepärane artikkel selle teema kohta.

Selles näites kasutame asümmeetrilisi krüpteerimisalgoritme. Asümmeetriliste algoritmide rakendamiseks on vajalik omada võtmepaari ja sertifikaati.

Võtmepaar koosneb kahest osast: privaatvõti ja avalik võti. Privaatvõti peab olema salajane, nagu tema nimi ütleb. Kasutame seda teabe dekrüpteerimiseks. Avalikku võtit saab jagada kellelegi. See võti on mõeldud andmete krüpteerimiseks. Nii saab iga kasutaja andmeid krüpteerida, kasutades avalikku võtit, kuid ainult privaatvõtme omanik võib seda teavet dekrüpteerida.

Sertifikaat on digitaalne dokument, mis sisaldab teavet kasutaja kohta, kellele sertifikaat kuulub, samuti avalikku võtit. Sertifikaadi omamine võimaldab kasutajal mis tahes andmeid allkirjastada ja saata need serverisse, mis saab selle allkirja kontrollida ja andmed dekrüpteerida.

Et sõnumit sertifikaadiga õigesti allkirjastada, tuleb see õigesti luua. Selleks luuakse kõigepealt Ruutokenis võtmepaar ja seejärel tuleb sertifikaat siduda selle võtmepaari avaliku võtmega. Sertifikaadil peab olema just see avalik võti, mis asub Ruutokenis, see on oluline. Kui me lihtsalt loome võtmepaari ja sertifikaadi otse rakenduse kliendipoolel, siis kuidas saab server hiljem seda krüpteeritud sõnumit dekrüpteerida? Ta ei tea ju midagi ei võtmepaarist ega sertifikaadist.

Kui sügavamale minna, siis võib internetist leida huvitavat teavet. On olemas teatud tõendamis keskused, mida usaldame. Need tõendamis keskused saavad väljastada sertifikaate kasutajatele, nad installivad need sertifikaadid oma serveritesse. Kui klient ühendub sellele serverile, näeb ta seda sertifikaati ja näeb, et see on välja antud tõendamis keskuse poolt, seega saab sellele serverile usaldada. Täiendavat teavet selle kohta, kuidas kõike õigesti seadistada, on internetis samuti palju. Näiteks võib alustada sellest.

Kui naasta meie ülesande juurde, siis lahendus näib olevat ilmne. Peame kuidagi looma oma sertifitseerimiskeskuse. Aga enne seda tuleb selgeks teha, mille alusel sertifitseerimiskeskus peaks kasutajale sertifikaadi välja andma, kuna tal pole selle kohta mingeid andmeid. (Näiteks tema nimi, perekonnanimi jne.) On olemas asi, mida nimetatakse sertifikaadi taotlemiseks. Rohkem selle standardi kohta saab lugeda näiteks vikipeediast. ru.wikipedia.org/wiki/PKCS
Kasutame versiooni 1.7 — PKCS#10.

Kava sertifikaadi genereerimise algoritmi kirjeldamiseks RutuTokenil (algallikas — dokumentatsioon):

  1. Kliendis loome võtmepaari ja salvestame selle RutuTokenile. (salvestamine toimub automaatselt)
  2. Kliendis loome sertifikaadi taotluse.
  3. Saadame selle taotluse serverisse.
  4. Sertifikaadi taotluse saamisel serveris, väljastame sertifikaadi oma sertifitseerimiskeskuse kaudu.
  5. Saadame selle sertifikaadi kliendile.
  6. Kliendis salvestame sertifikaadi RutuTokenile.
  7. Sertifikaat peab olema seotud selle võtmepaariga, mis loodi esimeses etapis.

Nüüd on selge, kuidas server saab kliendi allkirja dekodeerida, kuna see on ise selle sertifikaadi välja andnud.

Järgmises osas vaatame üksikasjalikult, kuidas seadistada oma sertifitseerimiskeskust põhjaliku avatud lähtekoodiga krüptograafia teegiga openSSL.

Allikas: habr.com

Osta usaldusväärne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid | ProHoster