Karanasan sa paggamit ng teknolohiya ng Rutoken para sa pagpaparehistro at pagpapahintulot sa mga user sa system (bahagi 1)

Magandang hapon Gusto kong ibahagi ang aking karanasan sa paksang ito.

Ang Rutoken ay mga solusyon sa hardware at software sa larangan ng authentication, seguridad ng impormasyon at electronic signature. Sa pangkalahatan, ito ay isang flash drive na maaaring mag-imbak ng data ng pagpapatunay na ginagamit ng user upang mag-log in sa system.

Sa halimbawang ito, ginagamit ang Rutoken EDS 2.0.

Upang gumana sa Rutoken na ito kailangan mo i-install ang driver sa mga bintana.

Para sa Windows, ang pag-install lamang ng isang driver ay nagsisiguro na ang lahat ng kailangan ay naka-install upang makita ng OS ang iyong Rutoken at maaaring gumana dito.

Maaari kang makipag-ugnayan sa Rutoken sa iba't ibang paraan. Maa-access mo ito mula sa server side ng application, o direkta mula sa client side. Ang halimbawang ito ay titingnan ang pakikipag-ugnayan sa Rutoken mula sa client side ng application.

Ang bahagi ng kliyente ng application ay nakikipag-ugnayan sa rutoken sa pamamagitan ng rutoken plugin. Ito ay isang program na naka-install nang hiwalay sa bawat browser. Para sa Windows kailangan mo lang i-download at i-install ang plugin, matatagpuan sa link na ito.

Iyon lang, ngayon ay maaari na tayong makipag-ugnayan sa Rutoken mula sa client side ng application.

Tinatalakay ng halimbawang ito ang ideya ng pagpapatupad ng algorithm ng awtorisasyon ng user sa system gamit ang challenge-response scheme.

Ang kakanyahan ng ideya ay ang mga sumusunod:

1. Nagpapadala ang kliyente ng kahilingan sa pahintulot sa server.
2. Tumutugon ang server sa isang kahilingan mula sa kliyente sa pamamagitan ng pagpapadala ng random na string.
3. Ang client pad ang string na ito na may random na 32 bits.
4. Pinirmahan ng kliyente ang natanggap na string gamit ang certificate nito.
5. Ipinapadala ng kliyente ang natanggap na naka-encrypt na mensahe sa server.
6. Bine-verify ng server ang lagda sa pamamagitan ng pagtanggap ng orihinal na hindi naka-encrypt na mensahe.
7. Inalis ng server ang huling 32 bits mula sa natanggap na hindi naka-encrypt na mensahe.
8. Inihahambing ng server ang natanggap na resulta sa mensaheng ipinadala noong humihiling ng pahintulot.
9. Kung pareho ang mga mensahe, ituturing na matagumpay ang pahintulot.

Sa algorithm sa itaas mayroong isang bagay bilang isang sertipiko. Para sa halimbawang ito, kailangan mong maunawaan ang ilang teorya ng cryptographic. Sa Habré meron mahusay na artikulo sa paksang ito.

Sa halimbawang ito, gagamit kami ng mga asymmetric encryption algorithm. Para ipatupad ang mga asymmetric na algorithm, dapat ay mayroon kang key pair at certificate.

Ang isang pares ng susi ay binubuo ng dalawang bahagi: isang pribadong susi at isang pampublikong susi. Ang pribadong susi, gaya ng ipinahihiwatig ng pangalan nito, ay dapat na lihim. Ginagamit namin ito upang i-decrypt ang impormasyon. Ang pampublikong susi ay maaaring ipamahagi sa sinuman. Ginagamit ang key na ito upang i-encrypt ang data. Kaya, maaaring i-encrypt ng sinumang user ang data gamit ang pampublikong susi, ngunit ang may-ari lamang ng pribadong susi ang makakapag-decrypt ng impormasyong ito.

Ang isang sertipiko ay isang elektronikong dokumento na naglalaman ng impormasyon tungkol sa user na nagmamay-ari ng sertipiko, pati na rin ang isang pampublikong susi. Sa pamamagitan ng isang sertipiko, maaaring lagdaan ng user ang anumang data at ipadala ito sa server, na maaaring i-verify ang lagda at i-decrypt ang data.

Upang malagdaan nang tama ang isang mensahe gamit ang isang sertipiko, kailangan mong gawin ito nang tama. Upang gawin ito, ang isang key pair ay unang ginawa sa Rutoken, at pagkatapos ay isang certificate ay dapat na naka-link sa pampublikong key ng key na ito pares. Ang sertipiko ay dapat na may eksaktong pampublikong susi na matatagpuan sa Rutoken, ito ay mahalaga. Kung gagawa lang kami ng key pair at isang certificate kaagad sa client side ng application, kung gayon paano made-decrypt ng server ang naka-encrypt na mensaheng ito? Pagkatapos ng lahat, wala siyang alam sa alinman sa key pair o sa sertipiko.

Kung sumisid ka nang mas malalim sa paksang ito, makakahanap ka ng kawili-wiling impormasyon sa Internet. May ilang partikular na awtoridad sa certification na malinaw na pinagkakatiwalaan namin. Ang mga awtoridad sa certification na ito ay maaaring mag-isyu ng mga certificate sa mga user; ini-install nila ang mga certificate na ito sa kanilang server. Pagkatapos nito, kapag na-access ng kliyente ang server na ito, nakikita niya ang mismong certificate na ito, at nakitang inisyu ito ng awtoridad sa sertipikasyon, na nangangahulugang mapagkakatiwalaan ang server na ito. Mayroon ding maraming impormasyon sa Internet tungkol sa kung paano i-set up nang tama ang lahat. Halimbawa, maaari kang magsimula dito.

Kung babalikan natin ang ating problema, mukhang halata ang solusyon. Kailangan mong gumawa ng sarili mong certification center kahit papaano. Ngunit bago iyon, kailangan mong malaman kung anong batayan ang dapat na mag-isyu ng sertipiko ang sentro ng sertipikasyon sa gumagamit, dahil wala siyang alam tungkol dito. (Halimbawa, ang kanyang unang pangalan, apelyido, atbp.) Mayroong tinatawag na kahilingan sa sertipiko. Higit pang impormasyon tungkol sa pamantayang ito ay matatagpuan, halimbawa, sa Wikipedia ru.wikipedia.org/wiki/PKCS
Gagamitin namin ang bersyon 1.7 - PKCS#10.

Ilarawan natin ang algorithm para sa pagbuo ng isang sertipiko sa Rutoken (orihinal na pinagmulan: ang babasahin):

1. Gumawa kami ng key pair sa client at i-save ito sa Rutoken. (awtomatikong nagaganap ang pag-save)
2. Lumilikha kami ng kahilingan sa sertipiko sa kliyente.
3. Mula sa kliyente ipinapadala namin ang kahilingang ito sa server.
4. Kapag nakatanggap kami ng kahilingan para sa isang sertipiko sa server, naglalabas kami ng sertipiko mula sa aming awtoridad sa sertipikasyon.
5. Ipinapadala namin ang certificate na ito sa kliyente.
6. Ise-save namin ang certificate ng Rutoken sa kliyente.
7. Dapat na nakatali ang certificate sa key pair na ginawa sa unang hakbang.

Ngayon ay naging malinaw kung paano magagawang i-decrypt ng server ang pirma ng kliyente, dahil ito mismo ang nagbigay ng sertipiko sa kanya.

Sa susunod na bahagi, titingnan namin nang mabuti kung paano i-set up ang iyong awtoridad sa certificate batay sa ganap na open-source cryptography library na openSSL.

Pinagmulan: www.habr.com