Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат / Хабр

1с-эдо

Управление ключевыми файлами и конвертация (rsa, pkey)

(1) openssl rsa [options]  <infile  >outfile

• -in <infile> Введите ключевой файл
• -passin pass:<password> Введите пароль защиты ключа
• -inform  <DER|NET|PEM> Введите формат ключа, по умолчанию PEM
• -out <outfile> Выходной ключевой файл
• -outform <DER|NET|PEM> Формат выходного ключа, по умолчанию – PEM
• -passout pass:<password> Пароль защиты выходного ключа
• -pubin Указывает, что ввод – это открытый ключ, а вывод по умолчанию – это пара ключей или закрытый ключ.
• -pubout Экспорт открытого ключа в файл (открытый ключ, как правило, не нужно шифровать)
• -des, -des3, -aes128, -aes192, -aes256 Указать алгоритм шифрования ключа
• -text Очистить ключевые параметры вывода текста
• -noout Не выводить ключ в файл
• -check Проверить согласованность
• -modulus Отображение ключевого модуля RSA

пример

# Извлечь публичный ключ ключа в отдельный файл
openssl rsa -in rsakey0.pem -pubout -out rsakey0.pub    

 # Формат ключа конверсии (DER-> PEM)
openssl rsa -in rsakeypair.der -inform DER -out rsakeypair.pem 
# Изменить алгоритм шифрования, снять защиту паролем
openssl rsa -in rsakeypair.pem -passin pass:123456  -des3 -out rsakeypair1.pem

(2) openssl pkey [options]  v1.0.1

(3) Другой способ преобразовать ключи формата PEM в ключи формата DER, которые могут использоваться Java JCE.

openssl pkcs8 -topk8 -inform PEM -outform DER -in <rsa_pem.key> -out <pkcs8_der.key> -nocrypt

(4) преобразование открытого ключа OpenSSL и формата открытого ключа OpenSSH

Формат открытого ключа, сгенерированного OpenSSL, несовместим с форматом открытого ключа OpenSSH. Если открытый ключ, сгенерированный OpenSSL, используется для настройки SSH-соединения, проверка завершится неудачно.

Формат открытого ключа OpenSSL (PEM):

Формат открытого ключа OpenSSH:

• Восстановить открытый ключ формата OpenSSH из закрытого ключа

ssh-keygen -y -f priKey.pem   > sshPubkey.pub

• Преобразование открытого ключа формата OpenSSL в формат OpenSSH

ssh-keygen  -i -m PKCS8 -f sslPubKey.pub〉 sshPubKey.pub # -m поддерживает PEM, PKCS8, RFC4716

• Преобразование открытого ключа формата OpenSSH в открытый ключ формата OpenSSL

ssh-keygen -e -m PEM  -f sshPubKey.pub> sslPubKey.pub # -m поддерживает PEM, PKCS8, RFC4716

Управление сертификатами

• Создать самоподписанный сертификат в формате X509

openssl req -x509 -new -days 365 -key rsakey.pem -out cert0.crt

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

Корневой сертификатЭто сертификат, выпущенный центром сертификации (Certificate Authority). Издатель сам является отправной точкой цепочки доверия. Он содержит информацию CA, открытый ключ CA и подпись этой информации собственным закрытым ключом.

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

• Создайте файл запроса, который требует, чтобы корневой сертификат выдал суб-сертификат

openssl req -new -key rsakey1.pem -out subcertreq.csr

Вам будет предложено ввести информацию отличительного имени DN (страна, город, организация, имя, адрес электронной почты и т. Д.), А также дополнительные атрибуты: пароль и необязательное название компании.

• Используйте корневой сертификат для выдачи субсертификатов

openssl x509 -req -in subcertreq.csr -CA cert0.crt -CAkey rsakey0.pem -CAcreateserial -days 365 -out subcert.crt

Вы также можете создать файл конфигурации ca и выдать суб-сертификат с помощью подкоманды управления ca (не проверено)

• Упакуйте сертификат и ключ в библиотеку в формате pkcs12

openssl pkcs12 -export -in subcert.crt -inkey rsakey1.pem -out subcert.p12

Необходимо ввести пароль файла pkcs12.

• Просмотр содержимого сертификата

openssl x509 -noout -text -in rootca.crt 

 openssl verify -CAfile rootca.crt subcert.crt

Используйте открытый ключ rootca.crt для проверки подписи в subcert.crt

Извлеките открытый ключ из сертификата

openssl x509 -in cert.pem  -noout -pubkey > pubkey.pem

Извлечь пару ключей

openssl pkcs12 -in cert.pfx  -nocerts -nodes -out keypari.pem

Извлеките открытый ключ из PKCS # 8

openssl req -in public.pem -noout -pubkey

Просмотр информации сертификата подписи pkcs7

 openssl pkcs7 -in  <pkcs7singedFile>  -inform DER  -print_certs

Документация

Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат

Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.

Про сертификаты:  открытая и закрытая часть эцп: как сделать экспорт |

Имея на руках сертификат, гражданин может получить доступ к порталу Госуслуг, заплатить налоги, защитить свою электронную почту, подписывать и шифровать документы и многое другое.

Сертификат, также как и паспорт, выдается на основании заявления и предоставления ряда документов. Перечень документов для получения сертификата есть на любом удостоверяющем центре, имеющим аккредитацию Минкомсвязи (новое название — министерство цифрового развития, связи и массовых коммуникаций). Заявление на паспорт имеет собственноручную подпись заявителя. В момент получения паспорта заявитель поставит свою подпись и в паспорт, которая будет заверена сотрудником паспортного стола и гербовой печатью. Фотография и умение владельца воспроизводить свою подпись и позволяют идентифицировать его как владельца конкретного паспорта.

По аналогичной схеме происходит и получение сертификата ключа проверки электронной подписи (СКПЭП). Сначала гражданин, желающий получить сертификат, должен приобрести «навык» в проставлении собственноручной подписи. Этот «навык» реализуется через получение заявителем ключевой пары, которая содержит открытый ключ или ключ проверки электронной подписи (КПЭП) и закрытый ключ или ключ электронной подписи, который, собственно, и позволяет генерировать электронную подпись и подписывать электронный документ. Идентификация электронной подписи под документом осуществляется по следующему алгоритму. Из сертификата определяется каким ключом (ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2021 с длиной ключа 64 или 128 байт) был подписан документ. По типу ключа определяется алгоритм хэширования, который использовался при подписании документа. Это может быть ГОСТ Р 34.11-94 или ГОСТ Р 34.11-2021 с длиной хэш 256 или 512 бит. По выбранному алгоритму считается хэш от исходного документа. А по значению посчитанного хэш от исходного документа, публичного ключа (КПЭП) и его параметрам (все это берется из сертификата СКПЭП) и проверяется достоверность электронной подписи под документом.

Для создания ключевой пары используются различные средства криптографической защиты информации (СКЗИ), поддерживающие криптографические алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2021. При этом следует помнить, что использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2021 года не допускается! СКЗИ, которые реализуют различные криптографические алгоритмы и протоколы могут быть как программными, так и аппаратными. Доступ к СКЗИ осуществляется через криптографические интерфейсы. Абсолютное большинство сертифицированных СКЗИ с российской криптографией поддерживает либо универсальный криптографический интерфейс PKCS#11, который поддерживается на всех платформах, либо интерфейс CSP и CryptoAPI от Микрософт на платформах MS Windows (далее MS CSP). Именно эти два криптографических интерфейса и поддерживаются, например, порталом Госуслуг. Именно эти два типа СКЗИ и будут рассматриваться далее:

Следует иметь ввиду, что если есть желание или необходимость работы с электронной подписью не только на платформе Windows, но и на других платформах (Linux, macOS и т.п.), то следует выбирать токены PKCS#11 с поддержкой российской криптографии.

Помимо основной функции, связанной с генерацией запроса, в утилите предусмотрены функции для работы с токенами и сертификатами:

Комбинированное поле (combobox) «Выберите токен:» на основном окне содержит список доступных СКЗИ для генерации ключевой пары. Если утилита генерации запроса запущена на платформе Windows и на ней установлены криптопровайдеры CSP с поддержкой российской криптографии, то в перечне доступных СКЗИ («Выберите токен:») будет определен и виртуальный токен «MS_CSP». Так что, если есть желание использовать криптопровайдер MS CSP, то он должен быть установлен в системе до запуска утилиты.

Для добавления поддержки нового токена PKCS#11 достаточно выбрать пункт меню «Управление Токенами->Добавить Токен». Добавление поддержки для нового токена состоит в выборе библиотеки PKCS#11 для подключаемого типа токенов/смарткарт и задании удобного имени (никнайма). При добавлении поддержки нового типа токенов (а также при запуске утилиты, если ранее была добавлена поддержка токенов) при подключенном (вставленном) токене будет затребован PIN-код для доступа к нему:

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

p11conf

:

Выбрав пункт «Управление Токенами->Механизмы Токена», можно посмотреть криптографические механизмы того или иного токена, например, есть ли поддержка алгоритма ГОСТ Р 34.10-2021. Для виртуального токена MS_CSP перечисляются все провайдеры CSP с поддержкой ГОСТ-алгоритмов и поддерживаемые ими механизмы:

Если выбранный токен не поддерживает выбранный тип ключевой пары, то будет выдано соответствующее сообщение:

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

И каждая роль связана с множеством различных OID-ов, включаемых в сертификат. Так, например, для доступа на портал Госуслуг необходимы следущие oid-ы:

{Госуслуги} {clientAuth, emailProtection, 1.3.6.1.4.1.311.20.2.2, 1.2.643.100.2.1, 
1.2.643.2.2.34.6, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.2.643.5.1.24.2.1.3, 
1.2.643.6.14, 1.2.643.3.215.4, 1.2.643.3.215.5, 1.2.643.3.215.6, 1.2.643.3.215.7, 
1.2.643.3.215.8, 1.2.643.3.215.9, 1.2.643.3.215.11, 1.2.643.3.215.12, 1.2.643.3.215.13, 1.3.6.1.4.1.40870.1.1.1, 1.2.643.2.64.1.1.1, 1.2.643.3.5.10.2.12, 1.2.643.6.3.2, 
1.2.643.5.1.24.2.46, 1.2.643.6.45.1.1.1, 1.2.643.5.1.24.2.30, 1.2.643.5.1.28.2, 
1.2.643.5.1.28.3, 1.2.643.3.202.1.8}

OID-ы для других ролей (например, «Площадка Газпромбанк», «Потребитель спирта» и т.д.) можно найти в исходном коде утилиты (переменная oid_roles_bad, оператор:

set oid_roses_bad {. . .}

).

Наличие такого количества oid-ов трудно понять. Речь идет о квалифицированных сертификатах, в которых присутствуют oid-ы ИНН, ОГРН, СНИЛС и т.п., которые однозначно идентифицируют и физическое лицо и юридическое лицо и, кажется, этого было бы достаточно для доступа на портал Госуслуг, да и на другие тоже. Но, Dura lex, sed lex — Закон суров, но это закон.

В поле «Наименование СКЗИ» необходимо указать название СКЗИ (токен/смарткарта, CSP), которое прописано в сертификате соответствия (не путать с сертификатом X509) ФСБ России или другом аналогичном документе, копию которого должна предоставляться в момент приобретения СКЗИ. В последующем значение этого поля войдет в сертификат.

Итак, определившись с СКЗИ и ключевой парой, можно приступать к заполнению электронного заявления/запроса на сертификат ключа проверки электронной подписи (СКПЭП):

Первым заполняется поле «Common Name», в которое заносится полное имя будущего владельца сертификата. Для физического лица это ФИО как в паспорте. Для юридического лица это наименование компании из ЕГРЮЛ. Эта информация для юридического лица автоматически будет продублирована в поле «Наименование организации» («O»):

При заполнении формы проверяется правильность заполнения полей ИНН, ОГРН, СНИЛС (при вводе не цифры поле становится красным, правильно заполненные поля становятся зеленоватыми), адреса электронной почты:

После заполнения всех полей запроса и нажатия кнопки «Finish» в итоге будет получен запрос на сертификат:

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

Напомним, что ключевая пара содержит два ключа: закрытый и открытый. Открытый ключ, который еще называют ключом проверки электронной подписи, отправляется в запрос на сертификат. Для просмотра сгенерированного запроса, который содержит и открытый ключ, используется меню «Сертификаты->Просмотр запроса»:

Закрытый ключ остается у заявителя на его токене, PIN-код (пароль) от которого необходимо хранить как зеницу ока Своего. А поскольку существует

однозначное соответствие

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

Теперь со всеми необходимыми документами, со сгенерированным запросом на флэшке можно идти в ближайший удостоверяющий центр и получать сертификат. Итак запрос поступает для выпуска сертификата в один из УЦ, созданных с учетом Федерального закона от 6 апреля 2021г. №63-ФЗ «Об электронной подписи»:

Запрос в УЦ пройдет стадии импорта, рассмотрения, утверждения и выпуска сертификата по данному запросу:

Выпущенный сертификат будет опубликован на одном из сервисов УЦ, откуда его можно будет скачать. А сейчас достаточно, чтобы выпущенный сертификат был экспортирован на флэшку заявителя:

И вот теперь, когда получен сертификат, осталось положить его на СКЗИ (PKCS#11, MS CSP) (Сертификаты->Импорт x509):

Убедиться, что сертификат находится на токене, можно просмотрев содержимое токена/смарткарты (Сертификаты->Просмотр x509 на токене):

Ну и чтобы это была «броня» (Дайте мне такую БУМАЖКУ! Окончательная Бумажка, Броня. (Собачье Сердце к/ф)), подключим токен к браузеру

Firefox

с поддержкой российской криптографии и найдем выпущенный сертификат в личных сертификатах (в числе таких сертификатах, для которых на токене имеется закрытый ключ):

Утилита CreateCSRCAFL63 разработана на

Tcl/Tk

. Для доступа к криптографическим функциям MS CSP и токенов PKCS#11 разработан пакет cwapi, реализующий требования к библиотекам C со стороны Tcl. Реализовать эти требования

не сложно

, но порой отнимает много времени в силу своей рутинности. И тут на помощь приходит общедоступная утилита

SWIG.

, которая позволяет создавать интерфейсные модули между библиотеками C/C и другими языками. Это не только Tcl, но и Java и другие. Проект очень хорошо документирован и имеет прекрасные примеры. Воспользоваться им не представляет труда. В нашем случае для получения интерфейсного модуля был написан простой исходный файл cwapi.i для утилиты swig:

%module cwapi
%inline %{
#include "cwapi.h"
%}
%include "cwapi_SWIG.h"

В файле cwapi.h находятся описания функций из основного проекта cwapi:

#ifdef __cplusplus
extern "C" {
#endif
    int CW_Initialize (char *configdir);
    int CW_Finalize ();
    int addp11mod (char *nickname, char *library);
    int remp11mod (char *nickname);
    char *  lmod ();
    char *  ltok ();
    char *  lcert (char *token, int priv_cert);
    char* createreq (char *token, char *subject, char *keyusage, int keyparams, int pem, char *skzi, char* role);
    char* viewx509 (char *nickname, int CertOrReq);
    char* x509pem (char *nickname);
    char*  x509fromfile(char *token, char *infile, char *trusts);
    int delcert (char *nickname, int priv_cert);
    int p12tofile (char *token, char *nickname, char *outfile);
    char*  p12fromfile(char *token, char *infile);
    char* lmech(char* token);
    char* tinfo(char* token);
#ifdef __cplusplus
}
#endif

Выполнив команду:

$export SWIG_LIB=/usr/local/swig-3.0.12/Lib 
$/usr/local/swig-3.0.12/swig -tcl8   -o cwapi_wrap.c cwapi_.i
$

в файле cwapi_wrap.c получим готовый интерфейсный модуль. Добавляем его в проект cwapi, пересобираем его и получаем новый пакет, который и используется в данной утилите.

Про сертификаты:  Сертификаты на продукцию. Черный металлопрокат. Оптом и в розницу

Для получения дистрибутива очень удобно использовать утилиту

freewrap

, при этом библиотека cwapi также включается непосредственно в дистрибутив. Исходный код утилиты и дистрибутивы доступны для платформ Windows и Linux.

Хотелось бы упомянуть еще об одной утилите, а именно о tcl2c. Эта утилита «заварачивает» tcl/tk-код в C-код.

Для получения исполняемого кода достаточно выполнить команду:

$cc -o create_csr_С create_csr.c -ltcl -ltk
$

В состав дистрибутивов для платформы Linux включен и дистрибутив на языке С со статическим подключением пакета cwapi.

Ключевые термины

DSS (Digital Signature Standard) – стандарт США на цифровую подпись. В основе стандарта лежит алгоритм, называемый DSA (Digital Signature Algorithm) и являющийся вариацией подписи Эль-Гамаля.

ГОСТ Р34.10-2001 – новый российский стандарт на алгоритм формирования и проверки ЭЦП. Основан на сложности взятия дискретного логарифма в группе точек эллиптической кривой, а также на стойкости хэш-функции по ГОСТ Р34.11-94. Размер формируемой цифровой подписи – 512 бит.

ГОСТ Р34.10-94 – российский стандарт на алгоритм формирования и проверки ЭЦП, действующий с 1995 года. В стандарте используется модификация схемы шифрования с открытым ключом Эль-Гамаля и алгоритм выработки хэш-функции по ГОСТ Р34.11-94.

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

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

Центр сертификации – организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи и отвечает за управление ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов.

Новый отечественный стандарт эцп

В 2001 г. был принят новый отечественный стандарт на алгоритм формирования и проверки ЭЦП. Его полное название следующее: “ГОСТ Р34.10-2001. Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи”.

Данный алгоритм был разработан главным управлением безопасности связи Федерального агентства правительственной связи и информации при Президенте Российской Федерации при участии Всероссийского научно-исследовательского института стандартизации. Новый стандарт разрабатывался с целью обеспечения большей стойкости алгоритма генерации ЭЦП.

В основе ГОСТ Р34.10-2001 лежат алгоритмы с использованием операций на эллиптических кривых. Стойкость ГОСТ Р34.10-2001 основывается на сложности взятия дискретного логарифма в группе точек эллиптической кривой, а также на стойкости хэш-функции по ГОСТ Р34.11-94. Размер формируемой цифровой подписи – 512 бит.

В целом алгоритм вычислений по алгоритму ГОСТ Р34.10-2001 аналогичен применяемому в предыдущем стандарте ГОСТ Р34.10-94. Сначала генерируется случайное число k, с его помощью вычисляется компонента r подписи.

Затем на основе компоненты r, числа k, значения секретного ключа и хэш-значения подписываемых данных формируется s-компонента ЭЦП. При проверке же подписи аналогичным образом проверяется соответствие определенным соотношениям r, s, открытого ключа и хэш-значения информации, подпись которой проверяется. Подпись считается неверной, если соотношения неверны.

Старый ГОСТ Р34.10-94 не отменен, и в настоящее время параллельно действуют два отечественных стандарта на ЭЦП. Однако необходимо отметить, что для прежнего ГОСТа принято ограничение: при реализации ЭЦП по стандарту ГОСТ Р34.10-94 разрешено использовать только 1024-битные значения параметра p.

Использование математического аппарата группы точек эллиптической кривой в новом ГОСТ Р34.10-2001 позволяет существенно сократить порядок модуля p без потери криптостойкости. Так, в стандарте указано, что длина числа р может быть 256 или больше бит.

Симметричная или асимметричная криптография?

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

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

1. Алгоритмы с открытым ключом работают намного (в сотни раз) медленнее классических алгоритмов с закрытым ключом. Это их самый главный недостаток. Связан он с тем, что основной операцией в системах с открытым ключом является возведение в степень по большому модулю 500-1000 битовых чисел, что при программной реализации производится намного медленнее, чем шифрование того же объема данных классическими способами.
2. Алгоритмы с открытым ключом требуют обеспечения достоверности открытых ключей, что порой превращается в довольно сложную задачу. То же самое относится и к протоколам цифровой подписи. Для управления открытыми ключами используют специальную инфраструктуру открытых ключей, обеспечивающую функции управления открытыми ключами.
3. Алгоритмы с открытым ключом чувствительны к атакам по выбранному открытому тексту.

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

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

1. Пользователь А генерирует случайный сеансовый ключК и зашифровывает им с помощью симметричного алгоритмаF_сим свое сообщение M:
2. Пользователь А получает из базы данных открытый ключ U пользователя Б и зашифровывает им сеансовый ключК:
3. Пользователь А посылает своему абоненту зашифрованное сообщение Cт и зашифрованный сеансовый ключCk. Для защиты от вскрытия “человек-в-середине” передаваемые данные могут быть дополнены цифровой подписью.
4. Пользователь Б расшифровывает полученный сеансовый ключCk с помощью своего закрытого ключа R:
5. Пользователь Б расшифровывает сообщение с помощью сеансового ключа К:

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

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

Сообщения об ошибках

Стандарт цифровой подписи dss

Во многих странах сегодня существуют стандарты на электронную (цифровую) подпись. Стандарт цифровой подписи DSS (Digital Signature Standard – DSS) был принят в США в 1991 году и пересмотрен в 1994 году.

В основе стандарта лежит алгоритм, называемый DSA (Digital Signature Algorithm) и являющийся вариацией подписи Эль-Гамаля. В алгоритме используется однонаправленная хеш-функция H(m). В качестве хэш-алгоритма стандарт DSS предусматривает использование алгоритма SHA-1.

Рассмотрим сам алгоритм генерации ЭЦП. Вначале для группы абонентов выбираются три общих (несекретных) параметра р, q и a:

Зная эти числа, каждый абонент системы случайно выбирает число х, удовлетворяющее неравенству 0 < х < q, и вычисляет

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

Предполагается, что открытые ключи всех пользователей указываются в некотором несекретном, но “сертифицированном” справочнике, который должен быть у всех, кто собирается проверять подписи. На этом этап выбора параметров заканчивается, и абоненты готовы к тому, чтобы формировать и проверять подписи.

Пусть имеется сообщение m, которое один из пользователей желает подписать. Для генерации подписи пользователь должен выполнить следующие действия:

1. Вычислить значение хеш-функции h = H(m) для сообщения m. Значение хеш-функции должно лежать в пределах 0 < h < q.
2. Затем сгенерировать случайное число k, 0 < k < q.
3. Вычислить r = (a^k mod p) mod q.
4. Определить s = [k^-1}(H(m) x * r)] mod q

В результате пользователь получит для сообщения m подпись, состоящую из пары чисел (r,s). Сообщение вместе с подписью может быть послано любому другому абоненту системы. Проверить подпись можно следующим образом:

1. Вычислить значение хеш-функции h = H(m) для сообщения m.
2. Проверить выполнение неравенств 0 < r < q, 0 < s < q.
3. Вычислить w = s^-1 mod q ;
4. Проверить выполнение равенства v = r. Если v = r, то подпись считается подлинной, иначе подпись считается недействительной.

В силу сложности вычисления дискретных логарифмов злоумышленник не может восстановить k из r или х из s, а следовательно, не может подделать подпись.

Стандарт цифровой подписи гост р34.10-94

В России принят стандарт ГОСТ Р34.10-94 “Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма”. В этом стандарте используется алгоритм, аналогичный алгоритму, реализованному в стандарте DSS.

Вначале, так же как и по стандарту DSS, для группы абонентов выбираются три общих (несекретных) параметра р, q и a:

Подпись сообщения m состоит из двух чисел (r, s), вычисляемых по следующим формулам:

где H(m) – результат вычисления хеш-функции для сообщения m.

На этом формирование подписи закончено, и сообщение m вместе с ЭЦП (r,s) может быть отправлено получателю. Теперь отметим отличия алгоритма формирования ЭЦП по ГОСТ Р34.10-94 от алгоритма DSS.

1. Перед вычислением подписи исходное сообщение обрабатывается разными функциями хеширования: в ГОСТ Р34.10-94 применяется отечественный стандарт на хеш-функцию ГОСТ Р34.11-94, в DSS используется SHA-1, которые имеют разную длину хеш-кода. Отсюда и разные требования на длину простого числа q: в ГОСТ Р34.

2. По-разному вычисляется компонента s подписи. В ГОСТ Р34.10-94 компонента s
вычисляется по формуле

а в DSS компонента s вычисляется по формуле

Последнее отличие приводит к соответствующим отличиям в формулах для проверки подписи.

В результате процедура проверки подписи по ГОСТ Р34.10-94 заключается в следующем. Получив [m, (r, s)], получатель вычисляет

Затем проверяется равенство вычисленного значения v и полученного в составе ЭЦП параметра r. Подпись считается корректной, если v = r.

В алгоритме создания ЭЦП по ГОСТ Р34.10-94, так же как и в алгоритме DSS, производятся достаточно сложные вычисления, требующие затрат вычислительных ресурсов. Для ускорения процесса генерации подписей по этим алгоритмам можно заранее вычислять некоторое количество значений параметра r, не зависящего от подписываемого сообщения.

Три, сертификат управления инструментом keytool

keytool – это инструмент управления ключами, сертификатами и библиотекой сертификатов, предоставляемый Java. Могут быть выполнены различные операции, такие как создание ключей и сертификатов.

Подкоманды keytool следующие:

-certreq Создать запрос сертификата-changealias Изменить псевдоним записи-delete удалить запись-exportcert Экспортный сертификат-genkeypair Создать пару ключей-genseckey Создать ключ-gencert Сгенерировать сертификат в соответствии с запросом сертификата-importcert Импортировать сертификат или цепочку сертификатов-importkeystore импортирует одну или все записи из других хранилищ ключей-keypasswd Изменить ключевой пароль записи-list Список записей в хранилище ключей-printcert Распечатать содержимое сертификата-printcertreq Распечатать содержимое запроса на сертификат-printcrl Распечатать содержимое файла CRL-storepasswd Изменить пароль хранилища хранилища ключей

Вы также можете использоватьkeytool -command_name -helpПросмотр справочной информации по каждой подкоманде

• Импортируйте сертификат из библиотеки pkcs12 в библиотеку сертификатов jks (формат хранилища ключей java)

keytool -importkeystore -srckeystore subcert.p12 -destkeystore subcert.jks -srcstoretype pkcs12

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

• Импортируйте сертификат в библиотеку jks

keytool -importcert -keystore subcert.jks -alias rootca -file rootcert.crt

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

Библиотека сертификатов или библиотека ключей может хранить как ключ, так и сертификат.Если только сертификат (сертификат содержит открытый ключ), но не закрытый ключ, сгенерированная библиотека является доверительной библиотекой.

Просмотр отпечатка сертификата

keytool -list -keystore <keystoreFile>  -alias  <aliasName>

Жду добавления …

Файл pfx / pkcs # 12 (pem)

Файлы, которые могут быть зашифрованы, несколько сертификатов или ключей могут храниться в одном файле, который в основном используется для импорта и экспорта сертификатов и закрытых ключей. Расширение обычно .pfx, .p12.

PEM в DER

 openssl x509 -outform der -in certificate.pem -out certificate.der

Сертификат формата PEM для P7B

 openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfileCAcert.cer

Формат PEM в PFX

 openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt-certfile CAcert.crt

DER в PEM

openssl x509 -inform der -in certificate.cer -out certificate.pem

P7B в PEM

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

P7B в PFX (сначала в PEM)

$ openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer$ openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -outcertificate.pfx -certfile CAcert.cer

PFX в PEM (весь контент в PFX хранится в файле формата pem)

openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

PKCS # 8 определяет синтаксис информации о закрытом ключе и синтаксис закрытого ключа шифрования. X509 определяет спецификации сертификата. Ключи обычно кодируются и хранятся с использованием DER и PEM. JCE в Java использует DER. OpenSSL в основном использует кодировку PEM.

Многие открытые ключи SSH используют формат openssh. Контент начинается с ssh-rsa, заканчивается RSA-1024, а средний – кодировкой Base64:

ssh-rsa  AAAAB3Nza…………………….cySYqQ==  RSA-1024

Краткие итоги

Для формирования электронной цифровой подписи могут быть применены алгоритмы RSA, Эль-Гамаля и другие. Во многих странах сегодня существуют стандарты на электронную цифровую подпись. Так, в Российской Федерации действуют стандарты на алгоритмы формирования и проверки ЭЦП ГОСТ Р34.10-94 и ГОСТ Р34.10-2001.

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

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

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

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

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

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