1. Функции шифрования
1.1. Основные термины
Криптопровайдер - внешнее программное обеспечение, осуществляющее функции хэширования, шифрования, криптографической защиты.
Криптоплагин - библиотека, которая обеспечивает взаимодействие между криптопровайдером и сервером или утилитами сервера. Каждый криптоплагин предназначен для взаимодействия с определённым криптопровайдером.
1.2. Общие настройки
Настройки указываются в конфигурационном файле firebird.conf.
CryptoPlugin
Параметр CryptoPlugin определяет имя криптоплагина,
который будет использоваться сервером для взаимодействия c КриптоПро.
Параметр имеет строковый тип.
По умолчанию используется криптоплагин crypto_api,
который размещен в каталоге plugins.
CryptoPlugin = Crypto_API
ProviderName
Задаёт имя или идентификатор используемого сервером криптопровайдера.
Должен поддерживаться криптоплагином. Если задаётся именем алгоритма с
символами кириллицы, они должны быть указаны в URL-encoding.
По умолчанию используется провайдер «GOST R 34.10-2012 Signature with Diffie-Hellman Key Exchange».
ProviderName = 81
HashMethod
Задаёт название или идентификатор алгоритма хэширования, используемого сервером.
Должен поддерживаться криптоплагином.
Если задаётся именем алгоритма с символами кириллицы,
они должны быть указаны в URL-encoding.
По умолчанию используется алгоритм хэширования,
заданный в ГОСТ Р 34.11-2012.
HashMethod = 32802
SymmetricMethod
Задаёт название или идентификатор алгоритма симметричного шифрования,
используемого сервером. Должен поддерживаться криптоплагином.
Если задаётся именем алгоритма с символами кириллицы,
они должны быть указаны в URL-encoding.
По умолчанию используется алгоритм шифрования, заданный в ГОСТ 28147-89.
SymmetricMethod = 26142
Доступные алгоритмы и провайдеры
ID |
Описание |
|---|---|
32798 |
ГОСТ Р 34.11/34.10-2001 |
32801 |
ГОСТ Р 34.11-2012/34.10-2012 256 бит |
32802 |
ГОСТ Р 34.11-2012/34.10-2012 512 бит |
26142 |
ГОСТ 28147-89 |
75 |
GOST R 34.10-2001 Signature with Diffie-Hellman Key Exchange |
80 |
GOST R 34.10-2012 (256) Signature with Diffie-Hellman Key Exchange |
81 |
GOST R 34.10-2012 (512) Signature with Diffie-Hellman Key Exchange |
1.3. Шифрование сессии
Для шифрования сетевого трафика используется плагин SRP,
который генерирует секретный ключ и использует его для
взаимодействия между клиентом и сервером.
Шифрование сессии управляется двумя параметрами в файле
firebird.conf: WireCrypt и WireCryptPlugin. Первый параметр
включает/отключает шифрование. Второй задает плагин шифрования. По
умолчанию это Arc4 (Alleged RC4) - реализация алгоритма RC4. Если
аутентификация выполняется плагином SRP, то используется криптографический ключ,
который делает шифрование сессии безопасным без необходимости обмена
ключами между сервером и клиентом явно.
Плагин Arc4 является "встроенным" в клиентскую библиотеку fbclient.dll.
Можно получить или написать другой плагин защиты канала передачи данных.
Для настройки плагинов используется файл plugins.conf .
Файл конфигурации состоит из двух типов блоков:
Plugin = <имя плагина> {
Module = <путь до библиотеки с плагином>
Config = <имя конфигурации>
}
Config = <имя конфигурации> {
<ключ> = <значение>
...
}
Например:
Plugin = Crypto_API {
Module = $(root)/plugins/Crypto_API
Config = Crypto_API_config
}
Config = Crypto_API_config {
TracePlugin = 0
KeyDirectory = $(root)/plugins/Crypto_API/keys
test = 1234
}
1.4. Шифрование базы данных
РЕД База Данных предоставляет механизм шифрования данных, хранящихся в базе данных. Шифруется не вся база данных, а только страницы с данными, индексы и страницы с блобами.
Для шифрования базы данных необходимо подключить плагин шифрования. РЕД База Данных не предоставляет такой плагин, но его можно написать самостоятельно или получить у сторонних разработчиков.
Примечание
Пример плагина шифрования в examples/dbcrypt не производит реального шифрования, это
просто пример того, как можно написать этот плагин.
Шифрование базы данных применяется для избежания двух основных проблем:
чтобы предотвратить утечку данных, если сервер базы данных взломан/физически украден;
когда база данных поставляется вместе с каким-либо приложением, т.е хоть БД и есть на руках у злоумышленника, но она зашифрована, а данные можно получить только через приложение.
В первом случае можно доверять серверу базы данных, он не модифицирован для кражи ключей, передающихся плагину безопасности, то есть этот ключ не будет отправлен на неподходящий сервер.
Во втором случае сервер может быть каким-то образом модифицирован для кражи ключей (если они передаются из приложения в плагин через код сервера) или даже данных (например,модифицированный сервер выгружает блоки данных из кэша, где они не зашифрованы). Поэтому плагин должен убедиться, что файлы сервера, содержащие исполнимый код, не модифицированы. Приложение перед отправкой ключа плагину должно получить подтверждение подлинности плагина (например, потребовать от него цифровую подпись).
Для эффективного разделения шифрования и доступа к ключу,
плагин шифрования базы данных разделён на две части:
само шифрование и держатель секретного ключа.
Плагин шифрования выполняет шифрование данных,
а плагин для хранения ключа отвечает за предоставлением ключа безопасным способом.
Этот плагин может быть получен из приложения или загружен каким-либо другим способом.
Для определения плагина держателя секретного ключа
в файле конфигурации нужно указать значение параметра KeyHolderPlugin.
Шифрование включается следующей командой:
ALTER DATABASE ENCRYPT WITH <имя плагина> [KEY <имя ключа шифрования>]
Шифрование в фоновом режиме начинается сразу после выполнения оператора. Работа с базами данных не нарушается во время шифрования.
Необязательное предложение KEY позволяет передать имя ключа для плагина шифрования.
Дешифрование базы данных выполняется следующей командой:
ALTER DATABASE DECRYPT
Шифрование базы данных с использованием плагина Crypto_Api
Для использования плагина Crypto_Api нужно указать "Crypto_Api" в операторе ALTER DATABASE
и параметре конфигурации KeyHolderPlugin.
Для шифрования базы данных плагином Crypto_Api должен быть
доступен хотя бы один ключевой контейнер КриптоПро.
Имя используемого ключевого контейнера указывается в параметре KEY оператора ALTER DATABASE.
Если ключевой контейнер защищен паролем, то предварительно нужно добавить его
в файл конфигурации плагина в формате: <Имя_контейнера> = <пароль>.
Для каждой базы данных, зашифрованной плагином Crypto_Api,
создается уникальный публичный ключ.
Публичные ключи хранятся в директории KeyDirectory,
указанной в конфигурации плагина Crypto_Api в файле plugins.conf.
В качестве имени ключевого файла используется имя ключевого контейнера КриптоПро,
который был указан в параметре KEY. Публичные ключи можно безопасно передавать по любому каналу связи,
так как они зашифрованы и могут быть использованы только совместно с оригинальным ключевым контейнером КриптоПро,
использовавшимся при шифровании.
Для последующего использования зашифрованной базы данных в системе должен обязательно присутствовать оригинальный ключевой контейнер КриптоПро и сгенерированный уникальный публичной ключ для конкретной базы данных. Дешифрование базы данных невозможно при наличии только ключевого контейнера или только публичного ключа.
Для дешифрования базы данных используется команда:
ALTER DATABASE DECRYPT
Если в системе присутствует оригинальный ключевой контейнер и публичный ключ для используемой базы данных, то база данных будет расшифрована и доступна без ключей шифрования.
Предупреждение
Если после полного дешифрования базы данных не удалить предыдущий ключ шифрования (файл публичного ключа), то он будет использован повторно при следущем запросе на шифрование базы данных. Чтобы сгенерировать новый ключ шифрования, обязательно нужно удалить использовавшийся ранее из директории файлов ключей.
Шифрование базы данных с использованием плагина RdbCrypt
Плагин шифрования RdbCrypt основан на открытой реализации блочного алгоритма шифрования AES-256.
RdbCrypt в использовании проще, чем Crypto_Api, но менее надежен,
потому что использует только один файл ключа.
Для использования RdbCrypt нужно указать "RdbCrypt" в операторе
ALTER DATABASE и в параметре конфигурации KeyHolderPlugin.
После этого запроса будет сгенерирован файл ключа в директории,
указанной в параметре KeyHolderPlugin конфигурации плагина с именем ключа,
который использован в запросе.
Если файл ключа уже существует, то он будет использован, а не сгенерирован новый.
Файл ключа не обазательно должен быть сгенерирован плагином, его можно
создать или использовать любой файл, который не превышает 1000 байт.
Например, можно использовать key.txt с текстом "секретный ключ".
Процесс дешифрования не отличается от Crypto_Api, кроме того что
используется только один файл ключа, который должен присутствовать в
директрии KeyDirecotry, указанной в конфигурации плагина.
1.5. Контроль целостности метаданных [1]
Контроль за целостностью метаданных осуществляется с помощью утилиты mint (входит в состав дистрибутива),
в основе которой лежит расчёт и последующая проверка хэша контролируемых объектов.
Утилита предназначена для извлечения и хэширования метаданных из баз данных,
а также для проверки ранее полученного хэша метаданных.
Таким образом, администратор может защитить структуру базы данных от изменений.
Утилита mint позволяет выбрать все метаданные из базы данных или
только их часть, по заданной маске, хэшировать их и сохранить в файл.
Также утилита может проводить проверку текущего состояния метаданных в
базе путем повторной выборки данных и сравнения результата с ранее сохраненным.
Утилита имеет следующие команды и опции:
Команды и опции |
Описание |
|---|---|
-M (mode) {extract|check} |
Режим работы утилиты. |
-o (object) |
Объекты для извлечения метаданных (системные и определенные пользователем, по умолчанию - все). |
-s (system) |
Извлекать метаданные системных объектов. |
-m (mask) |
Маска для извлечения метаданных из БД. |
-d (database) |
Имя базы данных, из которой будет производиться извлечение данных. |
-u (user) |
Имя пользователя для подключения к БД. |
-p (password) |
Пароль пользователя для подключения к БД. |
-C (certificate) |
Алиас сертификата пользователя. |
-r (repository) |
Хранилище с ключами шифрования. Значение игнорируется, если указана опция |
-P (pin) |
Пароль для закрытого ключа сертификата пользователя. |
-R (repository-algorithm) |
Алгоритм шифрования для хранилища ключей. |
-i (signature-file) |
Файл для сохранения|проверки хэша метаданных. |
-I (sign-algorithm) |
Название алгоритма цифровой подписи. |
-h (help) |
Отображает все опции |
-v (verbose) |
Подробный вывод. |
Существуют два режима работы утилиты – генерация контрольной суммы
(extract) и проверка (check).
Если маска не задана, то выбираются все метаданные из базы. В маске
можно использовать символ % - заменяет собой любое количество любых
символов.
Например, генерация подписи для всех системных объектов,начинающихся с
префикса RDB$, в базе данных security_version:
mint -M extract -m RDB$% -d ../security_version -u sysdba -p masterkey -r
test -R Crypto Pro GOST R 34.10-2012 KC1 CSP -i sign -I AT_SIGNATURE
проверка подписи для этих объектов:
mint -M check -m RDB$% -d ../security_version -u sysdba -p masterkey -r
test -R Crypto Pro GOST R 34.10-2012 KC1 CSP -i sign -I AT_SIGNATURE
Signature verification complete successfully
1.6. Контроль целостности файлов сервера [2]
Контроль за целостностью файлов сервера осуществляется с помощью утилиты
hashgen (входит в состав дистрибутива), в основе которой лежит
расчёт и последующая проверка хэш значений контролируемых объектов.
Утилита использует алгоритмы, предоставляемые криптопровайдером
КриптоПро.
При сборке дистрибутива, после того, как сформированы все компоненты
системы, запускается утилита формирования хэшей. Она хэширует файлы,
указанные в параметрах, и помещает результат в файл хэшей. Как правило
хэш формируется для бинарных файлов, файлов конфигурации, базы данных
безопасности security_version и т. д.
При инсталляции и в процессе эксплуатации администратор может
модифицировать список файлов, подлежащих контролю, и сгенерировать для
них файл хэшей-эталонов (например, добавить к контролируемым файлам файл
конфигурации) утилитой hashgen.
Включение режима контроля целостности файлов сервера выполняется путем
задания имени файла с хэшами в конфигурационном файле firebird.conf.
Имя этого файла задается параметром HashesFile. Если задано значение
этого параметра, то каждый раз при запуске сервера и регулярно в
процессе работы СУБД в соответствии со значением параметра
IntegrityCheckInterval, происходит проверка целостности файлов
сервера (только файлов на внешнем носителе). При этом файл с хэшами
считывается один раз при первой проверке.
При старте сервера, после того, как инициализируется криптопровайдер, производится считывание содержимого файла с хэшами. Далее, для каждого подконтрольного файла генерируется хэш с определенным для него алгоритмом и сверяется с эталонным значением хэша.
Файл хэшей должен содержать строки вида:
<хэш>:<алгоритм хэширования>:<имя файла>:<опция>
Где <опция> принимает значения S и M для файла на внешнем
носителе и в оперативной памяти соответственно.
Если какой-либо из хэшей не совпал, соответствующий файл не найден или
произошла ошибка при проверке, сервер делает соответствующую запись в
firebird.log и завершает работу. В зависимости от параметра
конфигурации IntegrityShutdownAttempts сервер совершает несколько
(или ноль) попыток прекратить свою работу безопасными средствами. Если
сервер не удалось выключить после заданного количества попыток, то
выполняется функция exit(FINI_ERROR);.
Формат запуска утилиты hashgen имеет следующий вид:
hashgen generate {-S|-M <PID>} <алгоритм хэширования> <файл1> [<файл2>] ...
Входные параметры утилиты – имя хэшируемого файла, алгоритм хэширования
и ключи -S (или --storage) и -M (или --memory) для
генерации хэшей файла на внешнем носителе и в оперативной памяти
соответственно.
В частности, опция -M применяется для всех библиотек и исполняемых
файлов, поддерживающих верификацию оперативной памяти процесса. В
качестве информации, подлежащей хэшированию, выступает образ
исполняемого файла или библиотеки в PE-формате для Windows и в
ELF-формате для Linux. хэшируются секции образа, изменение которых не
предусмотрено. Ниже представлен обобщенный список, некоторые из секций в
котором специфичны только для конкретного формата:
секция кода;
секция константных данных;
секции экспорта/импорта;
секция ресурсов.
Также этой утилитой можно производить проверку ранее созданных хэшей:
hashgen check [-P <PID>] <файл1> [<файл2>] ...
В качестве основного параметра выступают имена файлов, содержащие хэши.
Если хэш был сгенерирован для файла в памяти (т.е. с опцией
-M <PID>), то при проверке нужно указывать ключ -P <PID>. Иначе
проверка не будет выполнена, но утилита сообщит об успешном завершении.
Пример:
Генерация контрольной суммы алгоритмом ГОСТ Р 34.11-2012 для файла
security_version и сохранение в файл test.sign:
hashgen generate -S 32802 ../security_version>test.sign
Пример генерации хэша из оперативной памяти:
hashgen generate -M 1234 32802 rdbserver.exe > test.sign
Проверка хэшей:
hashgen check test.sign
../security_version: Success
Контрольная сумма в файле test.sign совпадает с контрольной суммой
исходного файла.
2. Настройка КриптоПро (на примере версии 4.0)
2.1. Настройка в операционной системе Windows
Общие настройки
Скачайте дистрибутив КриптоПро с официального сайта КриптоПРО в разделе загрузка. Доступ к скачиванию обеспечивается после регистрации на сайте.
Установите КриптоПро.
Настройте провайдер через Панель управления->КриптоПро CSP. На вкладке Алгоритмы настраиваются параметры для криптопровайдера (рисунок).
Рис. 2.1 Настройка алгоритмов
Название криптопровайдера –
GOST R 34.10-2012 Signature with Diffie_Hellman Key Exchange. Используется в параметреProviderNameфайла конфигурацииfirebird.conf;Параметры алгоритма шифрования – название алгоритма шифрования по умолчанию. Используется в параметре
SymmetricMethodфайла конфигурацииfirebird.conf;Параметры алгоритма подписи – название алгоритма ЭЦП по умолчанию, аналогично использование псевдонима
AT_SIGNATUREкак значение параметра для утилитыmint;Параметры алгоритма Диффи-Хелмана – название алгоритма, который будет использоваться по умолчанию для обмена сессионными ключами, аналогично использованию псевдонима
AT_KEYEXCHANGEкак значение параметра для утилитыmint.
Создание контейнеров с закрытыми ключами
Сессионные ключи генерируются плагином автоматически на время сессии. Для более безопасного обмена ими и аутентификации с использованием сертификата желательно использовать секретные ключи, которые хранятся в контейнерах.
Контейнеры сохраняются на считывателях, соответственно, необходимо настроить считыватели на вкладке оборудование.
Необходимо установить биологический датчик случайных чисел на вкладке оборудование.
Для генерирования секретных ключей можно воспользоваться средством КриптоПро
<каталог_установки_КриптоПро>\csptest.exe:csptest –keyset -provtype 81 -newkeyset -container <имя контейнера с секретным ключом>
Необходимо создавать ключи без паролей, так как при аутентификации используется режим
CRYPT_SILENT(чтобы не нарушать работу сервера(рисунок)).
Рис. 2.4 Запрос установки пароля
При создании ключа следует учитывать разграничение доступа среди пользователей Windows, то есть ключ, созданный одним пользователем, не будет доступен другому. Если сервер работает в режиме службы (то есть от имени системного пользователя), то необходимо, чтобы владельцем контейнера с серверными ключами была сама операционная система. Для этого необходимо при создании серверного контейнера указать опцию
-machinekeys:csptest –keyset -provtype 81 -newkeyset -container <имя контейнера> -machinekeys
Ключи хранятся в следующем разделе реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Crypto Pro\Settings\USERS\SID пользователя\Keys\<имя контейнера>
Пример создания ключевой пары
csptest -keyset -newkeyset -container test_keyq
CSP (Type:80) v4.0.9014 KC1 Release Ver:4.0.9842 OS:Windows CPU:IA32
FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 8411672
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 Cryptographic
Service Provider
Container name: "test_keys"
Signature key is not available.
Attempting to create a signature key...
a signature key created.
Exchange key is not available.
Attempting to create an exchange key...
an exchange key created.
Keys in container:
signature key
exchange key
Extensions:
OID: 1.2.643.2.2.37.3.9
PrivKey: Not specified - 17.08.2018 19:19:40 (UTC)
OID: 1.2.643.2.2.37.3.10
PrivKey: Not specified - 17.08.2018 19:19:59 (UTC)
Total: SYS: 0,515 sec USR: 0,359 sec UTC: 121,656 sec
[ErrorCode: 0x00000000]
Получение сертификата
Для получения сертификата в ОС Windows с помощью тестового центра КриптоПро выполните следующие действия:
Сформируйте запрос на получение сертификата с помощью утилиты
cryptcpи ее командыcreatrqst.-creatrqst -dn <RDN> [-provtype <N>] [-provname <CSP>] [-SMIME] [-nokeygen|-exprt] [-keysize <n>] [-hashAlg <OID>] [-ex|-sg|-both] [-ku|-km] [-cont <имя>] [-silent] [-pin <пароль>|-askpin] [-certusage <OIDs>] [-der] [-ext <расширение>] <имя файла>
При генерации запроса для клиентского сертификата необходимо указать заранее созданный клиентский контейнер с ключевой парой. Для этого используется опция
-nokeygen. Например:cryptcp -creatrqst -nokeygen -cont test_keys -provtype 81 -dn CN=tester test.req
Подробнее о командах и входных параметрах этой утилиты см. руководство по приложению командной строки
CryptCPпо адресу: http://cryptopro.ru/sites/default/files/products/cryptcp/cryptcp_5.0.x.pdf.Откройте в браузере ссылку http://www.cryptopro.ru/certsrv (тестовый удостоверяющий центр КриптоПро).
Нажмите "Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64"
Вставьте в поле "Base-64-шифрованный запрос сертификата" содержимое файла
test.reqи нажмите кнопку "Выдать".Сохраните файл по ссылке "Загрузить сертификат". Выгрузку сертификата необходимо проводить в формате Base64.
Установите полученный от УЦ сертификат в указанный ключевой контейнер:
certmgr -inst -store uMy -file certnew.cer -cont test_keys
Также в ОС Windows возможно получение сертификата с помощью тестового центра КриптоПро без самостоятельного создания запроса.
Для этого нажмите "Сформировать ключи и отправить запрос на сертификат" и заполните некоторые данные.
Выданные сертификаты можно посмотреть в окне "Сертификаты" (Пуск\(\longrightarrow\)КРИПТО-ПРО\(\longrightarrow\)Сертификаты).
Рис. 2.5 Просмотр сертификатов
2.2. Настройка в операционной системе Linux
Общие настройки
Архив с программным обеспечением можно загрузить с официального сайта КриптоПРО в разделе загрузка:
linux-ia32.tgz, linux-amd64.tgz.Примечание
По умолчанию при скачивании с сайта КриптоПро выдается лицензия на три месяца
Распакуйте архив и перейдите в распакованную папку.
Установите основные пакеты:
rpm -i lsb-cprocsp-base-X.X.X-X.rpm rpm -i lsb-cprocsp-rdr-X.X.X-X.rpm rpm -i lsb-cprocsp-capilite-X.X.X-X.rpm rpm -i lsb-cprocsp-kc1-X.X.X-X.rpm
На ОС, основанных на Debian (Debian/Ubuntu) сначала необходимо поставить (если не установлены) пакеты LSB из состава дистрибутива, а также пакет
alien, который является штатным средством для установки.rpm:apt-get install lsb-base alien lsb-core
Затем при помощи
alienпоставить необходимые пакеты CSP, например:alien -kci ./lsb-cprocsp-base-X.X.X-X.rpm alien -kci ./lsb-cprocsp-rdr-X.X.X-X.rpm alien -kci ./lsb-cprocsp-capilite-X.X.X-X.rpm alien -kci ./lsb-cprocsp-kc1-X.X.X-X.rpm
КриптоПро устанавливается по пути
/opt/cprocsp.По мере удовлетворения зависимостей, возможно, потребуется установить другие пакеты.
В Linux поддерживается провайдер
Crypto-Pro GOST R 34.10-2012 KC1 CSP.Настройте сервер «РЕД База Данных» на работу с криптоплагином. Для этого в конфигурационном файле
firebird.confуказываются следующие параметры:CryptoPlugin– имя криптоплагина (значение по умолчаниюCrypto_API)SymmetricMethod– алгоритм, используемый для симметричного шифрования. Можно указывать название алгоритма или его идентификатор в криптопровайдере (AlgId). Идентификатор алгоритма можно узнать утилитамиmintиhashgenпри запуске без параметров (параметрCryptoPluginв конфигурационном файле должен быть задан) или утилитой КриптоПроcsptestс параметрами-enum -info.Если используется неанглоязычные названия алгоритмов, необходимо перекодировать их в 2-х байтный юникод, напримерГОСТ Р 34.11-2012примет вид%D0%93%D0%9E%D0%A1%D0%A2+%D0%A0+34.11-2012HashMethod– название или идентификатор алгоритма хэширования. Способ представления аналогиченSymmetricMethod.ProviderName– название или идентификатор алгоритма криптопровайдера. Способ представления аналогиченSymmetricMethod.
Создание контейнера с закрытыми ключами
Предупреждение
Убедитесь, что пользователь операционной системы, от которого выполняется подключение, имеет достаточно прав на файл .registry_lock.
При использовании криптографических функций (например, во время многофакторной аутентификации) СУБД может падать внутри библиотеки КриптоПро версии 4.0 и ниже,
если на файл /var/opt/cprocsp/tmp/.registry_lock установлены неправильные права (владелец root, например).
В таком случае при попытке доступа к этому файлу из библиотеки КриптоПро происходит падение приложения, которое её использует.
Таким приложением может быть клиент (например, ISQL) или процесс сервера.
При этом выводится ошибка "support_mutex_open("registry_lock") failed:: Permission denied".
Ридеры (readers) — устройства размещения контейнеров (аппаратные токены, каталог для размещения файлов). Просмотр доступных ридеров:
$ csptest -enum -info -type PP_ENUMREADERS | iconv -f cp1251
Ридер
HDIMAGEразмещается на/var/opt/cprocsp/keys/<имя пользователя>/.Инициализация ридера
HDIMAGE(под правами root):cpconfig -hardware reader -add HDIMAGE store
Создадим контейнер с именем
testв локальном ридереHDIMAGE:$ csptest -keyset -provtype 81 -newkeyset -cont '\\.\HDIMAGE\test'
При установленном пакете
cprocsp-rdr-gui-gtkбудет показано графическое окно, где предложат двигать курсором мыши. Если такой пакет не установлен, будет предложено ввести любые символы с клавиатуры. После показа окна будет предложено указать пароль на контейнер (можно указать пустой, тогда пароль запрашиваться не будет) и снова предложат двигать курсором мыши.CSP (Type:81) v4.0.9006 KC1 Release Ver:4.0.9708 OS:Linux CPU:AMD64 FastCode:READY:AVX. AcquireContext: OK. HCRYPTPROV: 6679219 GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC1 CSP Container name: "card" Signature key is not available. Attempting to create a signature key... signature key created. Exchange key is not available. Attempting to create an exchange key... an exchange key created. Keys in container: signature key exchange key Extensions: OID: 1.2.643.2.2.37.3.9 OID: 1.2.643.2.2.37.3.10 Total: SYS: 0,030 sec USR: 0,160 sec UTC: 22,910 sec [ErrorCode: 0x00000000]
Ключи в Linux хранятся в
/var/opt/cprocsp/keys/<имя пользователя>/<имя контейнера>.Просмотр доступных контейнеров:
$ csptest -keyset -enum_cont -fqcn -verifyc
Удаление контейнера:
$ csptest -keyset -deletekeyset -cont '\\.\HDIMAGE\test'
Создание сертификата
Для получения сертификата в ОС Linux с помощью тестового центра КриптоПро выполните следующие действия:
Сформируйте запрос на получение сертификата с помощью утилиты
cryptcpи ее командыcreatrqst.-creatrqst -dn <RDN> [-provtype <N>] [-provname <CSP>] [-SMIME] [-nokeygen|-exprt] [-keysize <n>] [-hashAlg <OID>] [-ex|-sg|-both] [-ku|-km] [-cont <имя>] [-silent] [-pin <пароль>|-askpin] [-certusage <OIDs>] [-der] [-ext <расширение>] <имя файла>
При генерации запроса для клиентского сертификата необходимо указать заранее созданный клиентский контейнер с ключевой парой. Для этого используется опция
-nokeygen. Контейнер может быть указан без спецификатораHDIMAGE. Например:opt/cprocsp/bin/ia32/cryptcp -creatrqst -nokeygen -cont '\\.\HDIMAGE\test' -provtype 81 -dn 'CN=tester' test.req
Предупреждение
Контейнер с ключевой парой, который используется для генерации запроса на получение клиентского сертификата, должен принадлежать тому же пользователю, для которого запрашивается сертификат.
Подробнее о командах и входных параметрах этой утилиты см. руководство по приложению командной строки
CryptCPпо адресу: https://www.cryptopro.ru/sites/default/files/products/cryptcp/cryptcp_5.0.x.pdf.Откройте тестовый удостоверяющий центр КриптоПро.
Нажмите "Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64"
Вставьте в поле "Base-64-шифрованный запрос сертификата" содержимое файла
test.reqи нажмите кнопку "Выдать".Сохраните файл по ссылке "Загрузить сертификат". Выгрузку сертификата необходимо проводить в формате Base64.
Примечание
Не все браузеры в ОС Linux могут поддерживать выгрузку сертификатов. Это зависит от настроек сервера центра сертификации.
Устанавливаем, полученный от УЦ сертификат, в указанный ключевой контейнер:
$ certmgr -inst -store uMy -file certnew.cer -cont '\\.\HDIMAGE\test'
Чтобы посмотреть сертификаты, введите команду:
$ certmgr -list
Чтобы удалить сертификат, введите команду:
$ certmgr -delete 1 $ certmgr -delete -all