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

Добър ден Искам да споделя моя опит по тази тема.

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

В този пример се използва Rutoken EDS 2.0.

За да работите с този Rutoken се нуждаете инсталиране на драйвер на windows.

За Windows инсталирането само на един драйвер гарантира, че всичко необходимо е инсталирано, така че операционната система да вижда вашия Rutoken и да може да работи с него.

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

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

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

Този пример обсъжда идеята за внедряване на алгоритъм за оторизация на потребител в системата, използвайки схемата предизвикателство-отговор.

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

1. Клиентът изпраща заявка за оторизация до сървъра.
2. Сървърът отговаря на заявка от клиента, като изпраща произволен низ.
3. Клиентът допълва този низ с произволни 32 бита.
4. Клиентът подписва получения низ със своя сертификат.
5. Клиентът изпраща полученото криптирано съобщение до сървъра.
6. Сървърът проверява подписа, като получава оригиналното некриптирано съобщение.
7. Сървърът премахва последните 32 бита от полученото некриптирано съобщение.
8. Сървърът сравнява получения резултат със съобщението, което е изпратено при заявка за оторизация.
9. Ако съобщенията са еднакви, тогава авторизацията се счита за успешна.

В горния алгоритъм има такова нещо като сертификат. За този пример трябва да разберете някаква криптографска теория. На Хабре има страхотна статия по тази тема.

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

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

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

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

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

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

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

1. Ние създаваме двойка ключове на клиента и я записваме на Rutoken. (запазването става автоматично)
2. Създаваме заявка за сертификат на клиента.
3. От клиента изпращаме тази заявка до сървъра.
4. Когато получим заявка за сертификат на сървъра, ние издаваме сертификат от нашия сертифициращ орган.
5. Ние изпращаме този сертификат на клиента.
6. Ние запазваме сертификата Rutoken на клиента.
7. Сертификатът трябва да бъде обвързан с двойката ключове, създадена в първата стъпка.

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

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

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