Криптопро jcp linux ввод лицензии

Работа с КриптоПро на linux сервере

Ссылки

Лицензия

Для установки другой лицензии (под root):

Корневые сертификаты

Просмотр корневых сертификатов

Добавление корневых сертификатов (под root) из файла cacer.p7b

Необходимо последовательно добавить все сертификаты

Сертификаты

Список установленных сертификатов

certmgr -list , например:

Добавление реального сертификата

Добавить только сертификат (только проверка ЭЦП):

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

Закрытый ключ состоит из шести key-файлов:

Способ с дискетой или флешкой

Скопировать в корень дискеты или флэшки сертификат и приватный ключ (из каталога 999996.000 , 999996 — название (alias) контейнера):

Выполнить команду по копированию ключа с флэшки на диск, ключ попадет в пользовательское хранилище My .

gate@example.com — то, что прописано в поле E сертификата (можно посмотреть командой keytool —printcert -file /path/to/cert/client.cer ):

С жесткого диска

Скопировать приватный ключ в хранилище (контейнер), где — имя пользователя linux:

Поставить «минимальные» права:

Узнать реальное название контейнера:

Ассоциировать сертификат с контейнером, сертификат попадет в пользовательское хранилище My :

Если следующая ошибка, нужно узнать реальное название контейнера (см. выше):

Установить сертификат УЦ из-под пользователя root командой:

Проверка успешности установки закрытого ключа

Добавление тестового сертификата

Ввести пароль на контейнер test123 .

Ввести пароль на контейнер. По-умолчанию: 12345678

Удаление сертификата

Проверка сертификата

Просмотр всех атрибутов сертификата

В cryptcp нет необходимых инструментов для получения всех атрибутов сертификата. Поэтому следует использовать openssl , но настроив его.

Получаем SHA 1 хеши:

В цикле извлекаем сертификаты:

Настройка openssl для поддержки ГОСТ:

В файл /etc/ssl/openssl.cnf

Экспорт сертификатов на другую машину

Закрытые ключи к сертификатам находятся тут: /var/opt/cprocsp/keys . Поэтому эти ключи переносятся просто: создаем архив и переносим на нужную машину в тот же каталог.

Экспорт самих сертификатов (если их 14):

Переносим эти файлы на машину и смотрим, какие контейнеры есть:

И как обычно, связываем сертификат и закрытый ключ:

Если закрытый ключ и сертификат не подходят друг к другу, будет выведена ошибка:

Если все успешно:

Если нет закрытого ключа, то просто ставим сертификат:

Подписание документа ЭЦП

Пример создания ЭЦП (по SHA1 Hash):

[ReturnCode: x]	Описание	Возвращаемый код завершения в баше $?
0	успешно	0
0x8010006b	Введен неправильный PIN	107
0x2000012d	Сертификат не найден	45
0x20000065	Не удалось открыть файл	101

Проверка подписи ЭЦП

Для верифицирования сертификатов нужен сертификат удостоверяющего центра и актуальный список отзыва сертификатов, либо настроенный для этого revocation provider.

Корневой сертификат УЦ, список отзыва сертификата является одним из реквизитов самого сертификата.

Контрагенты когда открывают подписи в КриптоАРМ используют revocation provider, он делает проверки отзыва сертификата онлайн. Как реализована проверка в Шарепоинте не знаю. Знаю только что используется библиотека Крипто.Net

Проверка конкретной подписи из локального хранилища по его хешу:

Проверить, взяв сертификат из file1.sig , подпись файла file2.sig . Практически, надо использовать один и тот же файл:

[ReturnCode: x]	Текст	Описание	Возвращаемый код завершения в баше $?
0	Успешно	0
0x80091004	Invalid cryptographic message type	Неправильный формат файла	4
0x80091010	The streamed cryptographic message is not ready to return data	Пустой файл	16

Получение исходного файла

Получение исходного файла (сообщения):

Будет ругаться на сертификат (так как не будет проверки), но подпись удалит. Вариант с проверкой:

Источник

CryptoPro JCP на Linux. Как легко и безболезненно перейти на новый стандарт шифрования

Содержание статьи

С 2020 года использование шифрования по ГОСТ Р 34.10—2001 окажется под запретом, а значит, все организации, которые взаимодействуют с госструктурами, вынуждены срочно внедрять следующий стандарт — 2012 года. Если ты работаешь в одной из них, то не проходи мимо: в этой статье мы поговорим о том, как решить проблему, используя сервер на CentOS 7 и пакет CryptoPro JCP.

Если же ты впервые слышишь обо всем этом, то вот небольшая историческая справка.

В 1994 году в ФСБ разработали ряд стандартов и мер, призванных защитить обмен документами между организациями и другими участниками этого процесса. Одной из таких мер безопасности стала электронная цифровая подпись документов, а одним из стандартов — ГОСТ Р 34.10—94, где описан алгоритм формирования и проверки электронной цифровой подписи. Принятый и введенный в действие постановлением Госстандарта России от 23 мая 1994 года за номером 154, он проработал до 2001 года.

На смену пришел всем известный ГОСТ Р 34.10—2001 — улучшенный стандарт, разработанный для обеспечения большей стойкости алгоритма. Но время не стоит на месте, меняются алгоритмы и методы криптозащиты, и спустя одиннадцать лет ГОСТ Р 34.10—2001 меняют на ГОСТ Р 34.10—2012.

В новом стандарте первый вариант требований к параметрам остался прежним. Длина секретного ключа составляет порядка 256 бит, и предусмотрено использование хеш-функции с длиной хеш-кода 256 или 512 бит. Главное же отличие нового стандарта — варианты с дополнительными параметрами и схемами, в том числе хешированием по стандарту ГОСТ Р 34.11—2012 «Стрибог».

В феврале 2014 года ФСБ объявила о начале перехода на использование нового национального стандарта ГОСТ Р 34.10—2012 в средствах электронной подписи для информации, не содержащей сведений, составляющих государственную тайну. В свет вышел документ за номером 149/7/1/3-58 от 31 января 2014 года «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», он устанавливал следующие требования.

1. После 31 декабря 2013 года прекратить сертификацию средств электронной подписи на соответствие требованиям к средствам электронной подписи, утвержденным приказом ФСБ России от 27.12.2011 года № 796, если в этих средствах не предусматривается реализация функций в соответствии с ГОСТ Р 34.10—2012.
2. После 31 декабря 2018 года запретить использование ГОСТ Р 34.10—2001 для формирования электронной подписи.

Министерство связи даже создало план по переходу на стандарт (PDF). Однако на практике оказалось, что все не так просто, и переход пришлось отложить аж до 31 декабря 2019 года. Причины следующие.

1. Многие государственные и муниципальные органы не готовы перейти на использование нового стандарта электронной подписи ГОСТ-2012 из-за отсутствия поддержки на уровне ПО.
2. Чтобы выпускать сертификаты нового образца, необходимо оборудование, которое поддерживает новый ГОСТ, и сертификат Головного удостоверяющего центра, сформированный с использованием ГОСТ-2012. Удостоверяющие центры получили его только летом 2018 года. Необходимо дополнительное время, чтобы выпустить сертификаты для всех пользователей.

Сейчас в ходу два стандарта криптозащиты для работы ЭЦП, но тем, кто использует ГОСТ-2001, срочно нужно что-то предпринимать. Зима, как говорится, близко, а это значит, что нас ждет череда испытаний при внедрении поддержки ГОСТ-2012.

Ссылки на официальную документацию:

Я расскажу, как развернуть сертифицированное ФСБ средство СКЗИ (CryptoPro JCP) на сервере Linux под управлением Java JDK. Кстати, если ты до сих пор используешь ГОСТ-2001, на сайте CryptoPro есть замечательная статья, советую тебе ее прочесть, лишним не будет.

Весь документооборот между участниками обмена происходит по принципу СМЭВ (система межведомственного электронного взаимодействия). Приложение может быть участником такой системы, но может и не быть им вовсе, принцип обмена документами от этого не меняется. Для простоты понимания я нарисовал небольшую схему.

Взаимодействие приложений при обмене данных с криптографической защитой в рамках СМЭВ

Как всегда, встает вопрос о лицензировании программного решения. CryptoPro JCP недешев, и если одна рабочая станция обойдется в 1200 рублей, то серверные лицензии стоят значительно дороже — порядка 30 000 за каждое ядро (или два ядра процессора Intel с отключенным Hyper Threading).

Установка и настройка криптопровайдера

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

Первым делом создадим локального пользователя, под которым будет работать ПО, использующее подпись документов.

Правильно установим Java JDK. Скачиваем необходимый дистрибутив.

Распаковываем архив и проверяем, готова ли папка с Java для копирования.

Копируем папку в раздел для прикладного ПО. Я обычно использую /opt .

Проверяем, что скопировалось правильно. Если необходимо, меняем владельца папки на root.

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

В файл пишем следующее:

Если на сервере стоит несколько версий Java JDK, то необходимо зарегистрировать альтернативы для новой версии.

В меню выбираем опцию 2 (или ту, что приведет к использованию более новой версии Java). Не забываем поправить права на JRE systemPrefs.

Проверяем установленную версию Java.

$ java -version
java version «1.8.0_191»
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

Копируем папку с дистрибутивом CryptoPro JCP в раздел для прикладного ПО.

Проверяем, что все скопировалось корректно.

Выдаем права на запуск скриптов.

Проверяем владельца и права на папку, должен быть root. Переходим в нее.

Чтобы избежать проблем при инсталляции, проверь количество ядер на процессоре и сверься с лицензией. Узнать число ядер можно командой nproc .

Переходим к установке криптопровайдера JCP. Во время установки необходимо будет ответить на ряд вопросов.

Продолжение доступно только подписчикам

Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Источник

CryptoPro JCP на Linux. Как легко и безболезненно перейти на новый стандарт шифрования

Содержание статьи

Если же ты впервые слышишь обо всем этом, то вот небольшая историческая справка.

В 1994 году в ФСБ разработали ряд стандартов и мер, призванных защитить обмен документами между организациями и другими участниками этого процесса. Одной из таких мер безопасности стала электронная цифровая подпись документов, а одним из стандартов — ГОСТ Р 34.10—94, где описан алгоритм формирования и проверки электронной цифровой подписи. Принятый и введенный в действие постановлением Госстандарта России от 23 мая 1994 года за номером 154, он проработал до 2001 года.

На смену пришел всем известный ГОСТ Р 34.10—2001 — улучшенный стандарт, разработанный для обеспечения большей стойкости алгоритма. Но время не стоит на месте, меняются алгоритмы и методы криптозащиты, и спустя одиннадцать лет ГОСТ Р 34.10—2001 меняют на ГОСТ Р 34.10—2012.

В новом стандарте первый вариант требований к параметрам остался прежним. Длина секретного ключа составляет порядка 256 бит, и предусмотрено использование хеш-функции с длиной хеш-кода 256 или 512 бит. Главное же отличие нового стандарта — варианты с дополнительными параметрами и схемами, в том числе хешированием по стандарту ГОСТ Р 34.11—2012 «Стрибог».

Стрибог — бог древних славян, который покровительствует ветрам, погоде и всему, что связано с воздушным пространством. Возможно, и облачным технологиям тоже. Подробнее об этом шифре читай в статьях «Хешируем по ГОСТ 34.11—2012» и «Пишем простой локальный блокчейн с использованием „Стрибога“».

В феврале 2014 года ФСБ объявила о начале перехода на использование нового национального стандарта ГОСТ Р 34.10—2012 в средствах электронной подписи для информации, не содержащей сведений, составляющих государственную тайну. В свет вышел документ за номером 149/7/1/3-58 от 31 января 2014 года «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», он устанавливал следующие требования.

1. После 31 декабря 2013 года прекратить сертификацию средств электронной подписи на соответствие требованиям к средствам электронной подписи, утвержденным приказом ФСБ России от 27.12.2011 года №796, если в этих средствах не предусматривается реализация функций в соответствии с ГОСТ Р 34.10—2012.
2. После 31 декабря 2018 года запретить использование ГОСТ Р 34.10—2001 для формирования электронной подписи.

Министерство связи даже создало план по переходу на стандарт (PDF). Однако на практике оказалось, что все не так просто, и переход пришлось отложить аж до 31 декабря 2019 года. Причины следующие.

1. Многие государственные и муниципальные органы не готовы перейти на использование нового стандарта электронной подписи ГОСТ-2012 из-за отсутствия поддержки на уровне ПО.
2. Чтобы выпускать сертификаты нового образца, необходимо оборудование, которое поддерживает новый ГОСТ, и сертификат Головного удостоверяющего центра, сформированный с использованием ГОСТ-2012. Удостоверяющие центры получили его только летом 2018 года. Необходимо дополнительное время, чтобы выпустить сертификаты для всех пользователей.

Сейчас в ходу два стандарта криптозащиты для работы ЭЦП, но тем, кто использует ГОСТ-2001, срочно нужно что-то предпринимать. Зима, как говорится, близко, а это значит, что нас ждет череда испытаний при внедрении поддержки ГОСТ-2012.

Ссылки на официальную документацию:

Я расскажу, как развернуть сертифицированное ФСБ средство СКЗИ (CryptoPro JCP) на сервере Linux под управлением Java JDK. Кстати, если ты до сих пор используешь ГОСТ-2001, на сайте CryptoPro есть замечательная статья, советую тебе ее прочесть, лишним не будет.

Весь документооборот между участниками обмена происходит по принципу СМЭВ (система межведомственного электронного взаимодействия). Приложение может быть участником такой системы, но может и не быть им вовсе, принцип обмена документами от этого не меняется. Для простоты понимания я нарисовал небольшую схему.

Взаимодействие приложений при обмене данными с криптографической защитой в рамках СМЭВ

Как всегда, встает вопрос о лицензировании программного решения. CryptoPro JCP недешев, и если одна рабочая станция обойдется в 1200 рублей, то серверные лицензии стоят значительно дороже — порядка 30 000 за каждое ядро (или два ядра процессора Intel с отключенным Hyper Threading).

Установка и настройка криптопровайдера

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

Первым делом создадим локального пользователя, под которым будет работать ПО, использующее подпись документов.

Правильно установим Java JDK. Скачиваем необходимый дистрибутив.

Распаковываем архив и проверяем, готова ли папка с Java для копирования.

Копируем папку в раздел для прикладного ПО. Я обычно использую /opt .

Проверяем, что скопировалось правильно. Если необходимо, меняем владельца папки на root.

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

В файл пишем следующее:

Если на сервере стоит несколько версий Java JDK, то необходимо зарегистрировать альтернативы для новой версии.

В меню выбираем опцию 2 (или ту, что приведет к использованию более новой версии Java). Не забываем поправить права на JRE systemPrefs.

Проверяем установленную версию Java.

$ java -version
java version «1.8.0_191»
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

Копируем папку с дистрибутивом CryptoPro JCP в раздел для прикладного ПО.

Проверяем, что все скопировалось корректно.

Выдаем права на запуск скриптов.

Проверяем владельца и права на папку, должен быть root. Переходим в нее.

Чтобы избежать проблем при инсталляции, проверь количество ядер на процессоре и сверься с лицензией. Узнать число ядер можно командой nproc .

Переходим к установке криптопровайдера JCP. Во время установки необходимо будет ответить на ряд вопросов.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Иван Рыжевцев

Системный администратор с богатым опытом. Прошедший огонь, воду и медные трубы. Главный девиз в жизни: Нерешаемых задач нет, надо только найти правильное решение!

Источник