🥇Опит с прилагането на технологията Рутокен за регистрация и авторизация на потребители в системата (част 1)

Здравейте! Искам да споделя своя опит по тази тема.

Рутокен е хардуерно и софтуерно решение в областта на аутентификация, защита на информацията и електронен подпис. Поради същността си това е нещо като флашка, която може да съхранява аутентификационни данни, които потребителят използва за влизане в системата.

В този пример се използва Рутокен ЕЦП 2.0.

За работа с този Рутокен е необходимо да се инсталира драйвер за Windows..

За Windows, инсталирането на единствено драйвер осигурява всичко необходимо, за да може ОС да разпознае вашия Рутокен и да работи с него.

С Рутокен може да се взаимоодейства по различни начини. Може да имате достъп до него от сървърната част на приложението, или директно от клиентската част. В този пример ще разгледаме взаимодействието с Рутокен от клиентската част на приложението.

Клиентската част на приложението взаимодействието с рутокен става чрез рутокен плъгин. Това е програма, която се инсталира отделно на всеки браузър. За Windows е необходимо просто да изтеглите и инсталирате плъгина, намиращ се на тази връзка..

Всичко, сега можем да взаимодействаме с Рутокен от клиентската част на приложението.

В този пример е разгледана идея за реализация на алгоритъм за аутентификация на потребителя в системата, използвайки схема challenge-response.

Същността на идеята е следната:

Клиентът изпраща заявка за аутентификация на сървъра.
Сървърът в отговор на заявката от клиента изпраща произволен стринг.
Клиентът допълва този стринг с произволни 32 бита.
Клиентът подписва получения стринг с своя сертификат.
Клиентът изпраща на сървъра полученото кодирано съобщение.
Сървърът проверява подписа, получавайки оригиналното некодирано съобщение.
Сървърът отделя последните 32 бита от полученото некодирано съобщение.
Сървърът сравнява полученото съдържание с това, което е било изпратено при искането за аутентификация.
Ако съобщенията са идентични, аутентификацията се счита за успешна.

В предоставения по-горе алгоритъм има такова понятие като сертификат. В рамките на този пример е нужно да се разбере известна криптографска теория. На Хабър има отлична статия по тази тема..

В този пример ще използваме асиметрични алгоритми за криптиране. За да реализираме асиметрични алгоритми, е необходимо да разполагаме с ключова двойка и сертификат.

Ключовата двойка се състои от две части: частен ключ и публика ключ. Частният ключ, както предполага името му, трябва да бъде секретен. Ние го използваме за декриптиране на информация. Публичният ключ може да се раздава на всеки. Този ключ се използва за криптиране на данни. По този начин всеки потребител може да криптира данни, използвайки публичния ключ, но само притежателят на частния ключ може да декриптира тази информация.

Сертификатът е електронен документ, който съдържа информация за потребителя, на когото принадлежи сертификатът, както и публичния ключ. С сертификат, потребителят може да подпише всякакви данни и да ги изпрати на сървър, който може да проверява този подпис и да декриптира данните.

За да може правилно да се подпише съобщение с сертификат, е необходимо той да бъде правилно създаден. За това, на Рутокена първо се създава ключова двойка, а след това сертификатът трябва да бъде свързан с публичния ключ на тази ключова двойка. Сертификатът трябва да има именно този публичен ключ, който се намира на Рутокена, това е важно. Ако просто създадем ключова двойка и сертификат веднага на клиентската част на приложението, как после сървърът ще може да декриптира това криптирано съобщение? Нали той изобщо не знае нито за ключовата двойка, нито за сертификата.

Ако се задълбочим в тази тема, можем да намерим интересна информация в интернет. Съществуват определени удостоверяващи центрове, на които ние предварително се доверяваме. Тези удостоверяващи центрове могат да издават сертификати на потребителите, като тези сертификати се инсталират на техния сървър. След това, когато клиент се свърже с този сървър, той вижда самия сертификат и вижда, че е издаден от удостоверяващия център, което значи, че на този сървър може да се доверява. В интернет има много информация за това как да се настрои всичко правилно. Например, можете да започнете с това.

Ако се върнем към нашата задача, решението изглежда очевидно. Нужно е да създадем свой удостоверяващ център. Но преди това трябва да разберем на каква основа удостоверяващият център трябва да издава сертификат на потребителя, когато той не знае нищо за него (например неговото име, фамилия и т.н.). Има нещо, наречено заявка за сертификат. За повече информация относно този стандарт може да се разгледа, например, в Уикипедия. ru.wikipedia.org/wiki/PKCS
Ние ще използваме версия 1.7 — PKCS#10.

Ще опишем алгоритъм за генериране на сертификат на Рутокен (първоизточник — документация):

На клиента създаваме ключова двойка и я запазваме на Рутокен. (запазването става автоматично)
На клиента създаваме заявка за сертификат.
От клиента изпращаме тази заявка на сървъра.
При получаване на заявката за сертификат на сървъра, издаваме сертификат от нашия удостоверяващ център.
Изпращаме този сертификат на клиента.
На клиента запазваме сертификата на Рутокен.
Сертификатът трябва да бъде свързан с ключовата двойка, която беше създадена в първата стъпка.

Сега става ясно как сървърът ще може да декодира подписа на клиента, тъй като той сам е издал сертификата.

В следващата част ще разгледаме подробно как да настроим собствения си удостоверяващ център на базата на пълноценна криптографска библиотека с отворен код openSSL.

Източник: habr.com

Опит в прилагането на технологията Рутокен за регистрация и авторизация на потребители в системата (част 1)