В данной статье мы постараемся описать различные подходы, которые криптопровайдер «КриптоПро CSP» применяет для управления паролями ключевых контейнеров и носителей.

Будут рассмотрены возможности как классических версий CSP (до 4.0 включительно), так и изменения в CSP 5.0, позволившие добавить больше гибкости при использовании криптопровайдера. 

Базовые понятия и определения

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

Криптопровайдер (провайдер, CSP) - набор библиотек, реализующих интерфейс CryptoAPI.

Ключевой контейнер - сущность в постоянной памяти, которая хранит ключ подписи, сертификат и дополнительную служебную информацию. Чаще всего представляет собой набор из нескольких файлов с расширением «key». Может быть записан на любой поддерживаемый провайдером носитель.

ФКН - функциональный ключевой носитель, который реализует аппаратную криптографию. Ключи генерируются внутри ФКН и не покидают его никогда. К ФКН-ам относятся не только носители с неизвлекаемыми ключами, но и «облачный токен».  

Контекст контейнера - служебный объект в памяти криптопровайдера, которых хранит информацию о ключах. Чаще всего создаётся на основе прочитанной из ключевого контейнера информации. Типичный срок жизни контекста: от вызова CryptAcquireContext до CryptReleaseContext.

Объект провайдера - служебный глобальный объект, который создаётся на первом обращении к CSP и живет до завершения процесса. Он хранит в себе данные и структуры, которые являются общими для всех контекстов контейнеров, которые используются в рамках текущего процесса.

Приложение - пользовательская или системная программа/служба/плагин, которая загружает в своё адресное пространство криптопровайдер: csptest, cptools, CertEnroll, КриптоАРМ и т.д.

Важно понимать, что «КриптоПро CSP» является набором вспомогательных библиотек. Несмотря на то, что в дистрибутиве продукта идет несколько приложений, в том числе графических, чаще всего CSP функционирует внутри сторонних (в том числе и системных) приложений.

Режимы работы

«КриптоПро CSP» имеет два основных режима работы:

• режим библиотеки («в памяти приложений»);
• режим службы.

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

При выборе режима службы запускается отдельная системная служба, в которую загружаются все библиотеки провайдера, реализующие логику работы с ключами. Приложения же при обращениях к ключам работают исключительно через эту службу. То есть для всех приложений используется единый объект провайдера и общий набор свойств.

Логика работы с ключами «КриптоПро CSP 4.0»

Чтобы разобраться в логике работы с ключами новой версии криптопровайдера, рассмотрим, как она была организована в предшествующих версиях.

Допустим, приложение хочет открыть по имени некоторый ключевой контейнер и зачитать ключи для дальнейшего использования.

1. Провайдер перечисляет подключенные ключевые носители (считыватели) и ищет указанный контейнер.
2. Через окно провайдер запрашивает пароль для контейнера.
3. Если носителем является токен или смарт-карта, провайдер сразу предъявляет им пароль, иначе - запоминает в контексте контейнера для дальнейшего использования.
4. Зачитывает в оперативную память ключевой контейнер и с помощью пароля его расшифровывает.

Чтобы упростить взаимодействие пользователя с ключевым носителем / контейнером, предъявленный пароль сохраняется в контексте контейнера.

Это позволяет не запрашивать у пользователя пароль второй раз, если, например, между двумя операциями, требующими пароль, произошел разрыв связи с токеном.

Вне зависимости от того, чем является пароль на самом деле (прообразом для ключа шифрования ключей контейнера или паролем от токена, на котором несколько десятков контейнеров), провайдер поддерживает жесткую связь «1 пароль - 1 ключевой контейнер».

Сохранение в реестре

Предъявляемый через окно пароль можно сохранить в защищенном виде в реестре.

Если у администратора есть потребность запретить сохранение паролей, то можно воспользоваться групповой политикой:

Конфигурация компьютера - Административные шаблоны - Классические административные шаблоны - КРИПТО-ПРО - КриптоПро CSP - Запретить использование сохраненных паролей.

Запомненные пароли можно очистить через «Панель управления КриптоПро CSP» с помощью кнопки «Удалить запомненные пароли» на вкладке «Сервис».

Специфика некоторых токенов

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

Прежде всего, речь о функциональности паролей по умолчанию. Существует ряд ситуаций, когда токены могут использоваться для каких-то тестовых целей, не требующих серьезного уровня защиты. Тогда окно ввода пароля может только мешать. Для подобных ситуаций провайдер умеет запрашивать у токена, установлен ли в нем пароль по умолчанию. Если токен отвечает утвердительно, провайдер не выводит пользователю окно ввода пароля, а сразу неявно предъявляет известный пароль. Так, например, при работе с основной конфигурацией носителей Рутокен ЭЦП 2.0 этим паролем является 12345678. Провайдер никогда не запрашивает пароль по умолчанию.

Не менее важным является и внутреннее устройство токена. Чаще всего в токене реализована одна команда предъявления пароля, которая при успехе устанавливает в оперативной памяти устройства признак проведенной аутентификации. Это позволяет выполняться всем последующим командам, которые могут требовать повышенных привилегий: чтение или запись ключей, формирование подписи, выработка ключа обмена (расшифрование документа). В зависимости от внутреннего устройства токена данный признак может сохраняться как на несколько секунд и сбрасываться автоматически, так и поддерживаться до отключения токена из USB-порта. За редким исключением большинство производителей токенов следуют стандарту PC/SC и сбрасывают все признаки аутентификации и парольную информацию при получении аппаратного события RESET. Оно возникает, например, при обращении к токену из соседнего приложения.

Кэширование контекстов контейнеров

В провайдере «КриптоПро CSP 4.0» есть два важных кэша контекстов: кэш открытых контейнеров и кэш закрытых контейнеров.

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

Довольно часто пользовательские приложения «забывают» закрыть контекст контейнера (CryptReleaseContext) после работы. Это приводит к тому, что он вместе с паролем остаётся в памяти и ни при каком последующем использовании контейнера провайдер не потребует ни подключение токена, ни ввод пароля.

Кэш закрытых контейнеров позволяет сохранять в глобальном объекте провайдера контексты контейнеров, даже если они были корректно закрыты. По умолчанию данный кэш выключен и имеет максимальный размер в 0 элементов. Если пользователь хочет включить оптимизацию, что может быть полезно для нагруженных серверных систем, то он должен установить размер данного кэша (максимальное число хранимых закрытых контекстов) в ненулевое значение.

Это можно сделать как через конфигурацию CSP, так и через «Панель управления КриптоПро CSP» на вкладке «Безопасность» при использовании службы хранения ключей.

При превышении заданного размера из кэша «выталкиваются» самые старые элементы.

Логика работы с ключами «КриптоПро CSP 5.0»

В большинстве аспектов логика работы «КриптоПро CSP 5.0» является расширением логики CSP 4.0. Благодаря этому пользователь может самостоятельно настраивать тот режим работы, который больше соответствует решаемым задачам.

Рассмотрим тот же сценарий, что был описан ранее для CSP 4.0 - чтение ключевого контейнера:

1. Провайдер перечисляет подключенные ключевые носители (считыватели) и ищет указанный контейнер.
2. Провайдер запрашивает у ключевого носителя состояние аутентификации. Если на него был предъявлен пароль, то пробуем выполнить операцию.
3. Если пароль предъявлен не был, пробуем предъявить пароль из кэшей или реестра.
4. Пробуем выполнить операцию. Если получили ошибку - запрашиваем у пользователя пароль через графический интерфейс.
5. Выполняем операцию: чтение ключей, подпись, выработка ключа обмена.

Наиболее существенным отличием от CSP 4.0 является то, что теперь провайдер запрашивает пароль только тогда, когда он действительно нужен.

Забыть пароль на токене

Существует несколько способов заставить токен сбросить признак аутентификации:

1. Дождаться аппаратного RESET. На Windows он происходит примерно раз в минуту для каждого неиспользуемого носителя. Также он может происходить при смене процесса, использующего носитель. Тем не менее, как уже было сказано ранее, это наименее надежный способ, т.к. некоторые токены (например, «Рутокен») могут не реагировать на RESET.
2. Предъявить в CSP NULL в качестве пароля: CryptSetProvParam(PP_KEYEXCHANGE_PIN, NULL). Провайдер распознает данный вызов как запрос на сброс аутентификации и, если токен поддерживает эту функцию, пошлет на него явную команду с требованием забыть пароль.
3. «Инструменты КриптоПро» (cptools) - «Управление носителями» - «Забыть пароль». По сути это графическая обертка вокруг отправки «нулевого» пароля.
4. csptest -keys -cont “\\.\Aktiv Rutoken ECP 0” -nullpass

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

Кэши паролей

В CSP 5.0 введена классификация паролей. Они могут быть:

• контейнерные - один пароль для одного ключевого контейнера: Реестр, Директория, Облачный токен, флэшки;
• носителей - один пароль на весь ключевой носитель: почти все токены и смарт-карты;
• разблокирующие - используются для выполнения административных действий: сброс числа попыток, смена пароля носителя и т.п.

В CSP 5.0 существует три вида кэшей паролей: локальный, глобальный и отключенный.

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

Глобальный кэш паролей - это кэш, существующий в рамках глобального объекта провайдера. Он является общим для всех контекстов, используемых в рамках одного процесса. При использовании CSP в режиме службы данных кэш является общим для всех процессов. Пароли в данном кэше разделены по пользователям и зашифрованы на разных ключах: несколько одновременно работающих пользователей на одной машине никогда не получат доступ к паролям друг друга. По умолчанию глобальными являются все пароли носителей.

Схематически глобальный кэш паролей можно изобразить так:

Свойства глобального кэша:

• пароль носителя живет до закрытия приложения (или явного указания на его удаление);
• в режиме службы пароль носителя живет до перезапуска службы;
• в режиме службы на Windows глобальный кэш очищается при блокировании рабочего стола пользователя.

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

Настройка кэшей паролей

Настроить вид кэширования пароля можно через значение AuthPositions, установленное в ключе реестра

[HKLM\SOFTWARE\WOW6432Node\Crypto Pro\Cryptography\CurrentVersion\Parameters].

В него нужно установить значение вида 0xabc, где a - режим для разблокирующих паролей, b - для паролей носителей, c - для контейнерных. Режимы задаются следующими значениями:

• 0 - по умолчанию;
• 1 - отключенный;
• 2 - локальный;
• 3 - глобальный.

Примеры использования:

• режим по умолчанию: 0x132 (оно же 0x000);
• логика кэширования CSP 4.0: 0x122 (оно же 0x020);
• глобальное кэширование контейнерных паролей: 0x133 (оно же 0x003).

Запрет кэширования для ФКН

При использовании ФКН есть возможность не кэшировать пароль вне зависимости от настроек AuthPositions. Для этого в окне ввода пароля нужно установить галочку «Требовать пароль на каждую операцию».

В отличие от пассивных ключевых носителей в случае ФКН криптографические операции происходят на самом носителе. Установка этой галочки заставляет провайдер не просто не запоминать пароль, но и вызывать команду «Забыть пароль» после каждой криптографической операции. Это позволяет гарантировать, что на токене будут выполнены только те операции, для санкционирования которых был введен пароль.

Также можно воспользоваться групповой политикой, которая форсирует установку данной галочки и запретит её снятие:

Конфигурация компьютера - Административные шаблоны - Классические административные шаблоны - КРИПТО-ПРО - КриптоПро CSP - Требовать пароль функциональной смарт-карты для каждой операции.

Агафьин С.С.,

начальник отдела разработки ФКН,

компания КриптоПро