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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster