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

Добрый день! Хочу поделиться своим опытом по данной теме.

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

В данном примере используется Рутокен ЭЦП 2.0.

Для работы с этим Рутокеном необходимо установить драйвер на windows.

Для windows, установка одного лишь драйвера, обеспечивает установку всего, что нужно, чтобы ОС увидела ваш Рутокен и с ним можно было работать.

С Рутокеном можно взаимодействовать различными способами. Можно получить доступ к нему из серверной части приложения, а можно сразу из клиентской. В данном примере будет рассмотрено взаимодействие с Рутокеном из клиентской части приложения.

Клиентская часть приложения взаимодействует с рутокеном через рутокен плагин. Это программа, которая отдельно устанавливается на каждый браузер. Для windows необходимо просто скачать и установить плагин, находящийся по данной ссылке.

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

В данном примере рассмотрена идея реализации алгоритма авторизации пользователя в системе с использованием схемы chеllange-response.

Суть идеи в следующем:

Клиент отправляет запрос на авторизацию на сервер.
Сервер в ответ на запрос от клиента отправляет случайную строку.
Клиент дополняет эту строку случайными 32 битами.
Клиент подписывает полученную строку своим сертификатом.
Клиент отправляет на сервер полученное закодированное сообщение.
Сервер проверяет подпись, получая исходное не закодированное сообщение.
Сервер отсоединяет последние 32 бита от полученного не закодированного сообщения.
Сервер сравнивает полученный результат с тем сообщением, которое было отправлено при запросе на авторизацию.
Если сообщения одинаковые, то авторизация считается успешной.

В приведенном выше алгоритме есть такое понятие, как сертификат. В рамках данного примера нужно понимать некоторую криптографическую теорию. На Хабре есть отличная статья на эту тему.

В данном примере будем использовать асимметричные алгоритмы шифрования. Для реализации асимметричных алгоритмов необходимо иметь ключевую пару и сертификат.

Ключевая пара состоит из двух частей: приватный ключ и публичный ключ. Приватный ключ, как следует из его названия, должен быть секретным. Мы его используем для расшифровки информации. Публичный ключ можно раздать кому угодно. Этот ключ используется для шифрования данных. Таким образом любой пользователь может зашифровать данные, используя публичный ключ, но только владелец приватного ключа может расшифровать эту информацию.

Сертификат — это электронный документ, который содержит в себе информацию о пользователе, которому принадлежит сертификат, а также публичный ключ. Имея сертификат, пользователь может подписать любые данные и отправить их на сервер, который может проверить эту подпись и расшифровать данные.

Чтобы правильно можно было подписать сообщение сертификатом, нужно правильно его создать. Для этого на Рутокене сначала создается ключевая пара, а потом к публичному ключу этой ключевой пары должен привязываться сертификат. Сертификат должен иметь именно тот публичный ключ, который находится на Рутокене, это важно. Если мы просто создадим ключевую пару и сертификат сразу на клиентской части приложения, то каким образом потом сервер сможет расшифровать это зашифрованное сообщение? Ведь он совсем ничего не знает ни о ключевой паре, ни о сертификате.

Если глубже окунуться в эту тему, то можно найти интересную информацию в интернете. Существуют некие удостоверяющие центры, которым мы заведомо доверяем. Эти удостоверяющие центры могут выдавать сертификаты пользователям, они эти сертификаты устанавливают на свой сервер. После этого, когда клиент обращается к этому серверу, он видит этот самый сертификат, и видит, что он был выдан удостоверяющим центром, а значит этому серверу можно доверять. Подробнее про то, как правильно все настроить, в интернете тоже полно информации. К примеру можно начать с этого.

Если вернуться к нашей задаче, то решение кажется очевидным. Нужно каким-то образом сделать свой удостоверяющий центр. Но перед этим нужно разобраться, а на основании чего удостоверяющий центр должен выдавать сертификат пользователю, ведь он о нем ничего не знает. (Например его имя, фамилия и т.д.) Есть такая штука, которая называется запрос на сертификат. Подробнее про этот стандарт можно глянуть, например, на википедии ru.wikipedia.org/wiki/PKCS
Мы будем использовать версию 1.7 — PKCS#10.

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

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

Теперь становится понятно, как сервер сможет расшифровать подпись клиента, ведь он сам выдал ему сертификат.

В следующей части мы подробно рассмотрим, как настроить свой удостоверяющий центр на основе полноценной криптографической библиотеки с открытым исходным кодом openSSL.

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