Добры дзень! Жадаю падзяліцца сваім досведам па дадзенай тэме.
Рутокен - гэта апаратныя і праграмныя рашэнні ў галіне аўтэнтыфікацыі, абароны інфармацыі і электроннага подпісу. У сутнасці гэта такая флэшка, якая можа захоўваць у сабе аўтэнтыфікацыйныя дадзеныя, якія карыстач выкарыстоўвае для ўваходу ў сістэму.
У дадзеным прыкладзе выкарыстоўваецца Рутокен ЭЛП 2.0.
Для працы з гэтым Рутакенам неабходна.
Для windows, усталёўка аднаго толькі драйвера, забяспечвае ўсталёўку ўсяго, што трэба, каб АС убачыла ваш Рутокен і з ім можна было працаваць.
З Рутакен можна ўзаемадзейнічаць рознымі спосабамі. Можна атрымаць доступ да яго з сервернай часткі дадатку, а можна адразу з кліенцкай. У дадзеным прыкладзе будзе разгледжана ўзаемадзеянне з Рутакенам з кліенцкай часткі прыкладання.
Кліенцкая частка прыкладання ўзаемадзейнічае з рутокен праз рутокен убудова. Гэта праграма, якая асобна ўстанаўліваецца на кожны браўзэр. Для windows неабходна проста спампаваць і ўсталяваць убудову, .
Усё, зараз мы можам ўзаемадзейнічаць з Рутокен з кліенцкай часткі прыкладання.
У дадзеным прыкладзе разгледжана ідэя рэалізацыі алгарытму аўтарызацыі карыстальніка ў сістэме з выкарыстаннем схемы chеllange-response.
Сутнасць ідэі ў наступным:
- Кліент дасылае запыт на аўтарызацыю на сервер.
- Сервер у адказ на запыт ад кліента дасылае выпадковы радок.
- Кліент дапаўняе гэты радок выпадковымі 32 бітамі.
- Кліент падпісвае атрыманы радок сваім сертыфікатам.
- Кліент адпраўляе на сервер атрыманае закадаванае паведамленне.
- Сервер правярае подпіс, атрымліваючы зыходнае незакадаванае паведамленне.
- Сервер адлучае апошнія 32 біта ад атрыманага не закадаванага паведамлення.
- Сервер параўноўвае атрыманы вынік з тым паведамленнем, якое было даслана пры запыце на аўтарызацыю.
- Калі паведамленні аднолькавыя, то аўтарызацыя лічыцца паспяховай.
У прыведзеным вышэй алгарытме ёсць такое паняцце, як сертыфікат. У рамках дадзенага прыкладу трэба разумець некаторую крыптаграфічную тэорыю. На Хабры ёсць .
У дадзеным прыкладзе будзем выкарыстоўваць асіметрычныя алгарытмы шыфравання. Для рэалізацыі асіметрычных алгарытмаў неабходна мець ключавую пару і сертыфікат.
Ключавая пара складаецца з дзвюх частак: прыватны ключ і публічны ключ. Прыватны ключ, як след з яго назову, павінен быць сакрэтным. Мы яго выкарыстоўваем для расшыфроўкі інфармацыі. Публічны ключ можна раздаць каму заўгодна. Гэты ключ выкарыстоўваецца для шыфравання дадзеных. Такім чынам любы карыстач можа зашыфраваць дадзеныя, выкарыстаючы публічны ключ, але толькі ўладальнік прыватнага ключа можа расшыфраваць гэтую інфармацыю.
Сертыфікат - гэта электронны дакумент, які змяшчае ў сабе інфармацыю аб карыстальніку, якому належыць сертыфікат, а таксама публічны ключ. Маючы сертыфікат, карыстач можа падпісаць любыя дадзеныя і адправіць іх на сервер, які можа праверыць гэты подпіс і расшыфраваць дадзеныя.
Каб правільна можна было падпісаць паведамленне сертыфікатам, трэба правільна яго стварыць. Для гэтага на Рутакене спачатку ствараецца ключавая пара, а потым да публічнага ключа гэтай ключавой пары павінен прывязвацца сертыфікат. Сертыфікат павінен мець менавіта той публічны ключ, які знаходзіцца на Рутакене, гэта важна. Калі мы проста створым ключавую пару і сертыфікат адразу на кліенцкай частцы прыкладання, то якім чынам потым сервер зможа расшыфраваць гэтае зашыфраванае паведамленне? Бо ён зусім нічога не ведае ні аб ключавой пары, ні аб сертыфікаце.
Калі глыбей акунуцца ў гэтую тэму, то можна знайсці цікавую інфармацыю ў інтэрнэце. Існуюць нейкія якія сведчаць цэнтры, якім мы загадзя давяраем. Гэтыя якія сведчаць цэнтры могуць выдаваць сертыфікаты карыстачам, яны гэтыя сертыфікаты ўсталёўваюць на свой сервер. Пасля гэтага, калі кліент звяртаецца да гэтага сервера, ён бачыць гэты самы сертыфікат, і бачыць, што ён быў выдадзены які сведчыць цэнтрам, а значыць гэтаму серверу можна давяраць. Падрабязней пра тое, як правільна ўсё наладзіць, у інтэрнэце таксама поўна інфармацыі. .
Калі вярнуцца да нашай задачы, тое рашэнне здаецца відавочным. Трэба нейкім чынам зрабіць свой які сведчыць цэнтр. Але перад гэтым трэба разабрацца, а на падставе чаго які сведчыць цэнтр павінен выдаваць сертыфікат карыстачу, бо ён пра яго нічога не ведае. (Напрыклад яго імя, прозвішча і г.д.) Ёсць такая штука, якая называецца запыт на сертыфікат. Падрабязней пра гэты стандарт можна зірнуць, напрыклад, на вікіпедыі
Мы будзем выкарыстоўваць версію 1.7 – PKCS#10.
Апішам алгарытм фарміравання сертыфіката на Рутокене (першакрыніца ):
- На кліенце ствараем ключавую пару і захоўваем яе на Рутакен. (захаванне адбываецца аўтаматычна)
- На кліенце ствараем запыт на сертыфікат.
- З кліента дасылаем гэты запыт на сервер.
- Пры атрыманні запыту на сертыфікат на серверы, выпісваем сертыфікат сваім які сведчыць цэнтрам.
- Адпраўляем гэты сертыфікат на кліент.
- На кліенце захоўваем сертыфікат на Рутакен.
- Сертыфікат павінен прывязацца да той ключавой пары, якая была створана на першым кроку.
Цяпер становіцца зразумела, як сервер зможа расшыфраваць подпіс кліента, бо ён сам выдаў яму сертыфікат.
У наступнай частцы мы падрабязна разгледзім, як наладзіць свой які сведчыць цэнтр на аснове паўнавартаснай крыптаграфічнай бібліятэкі з адчыненым зыходным кодам openSSL.
Крыніца: habr.com