Сертификаты цифровых подписей RSA vs DSA: кто победит в бою? | Портал о системах видеонаблюдения и безопасности

Почему возникает ошибка при генерации ключа егаис?

Ошибка при генерации транспортного ключа для ЕГАИС иногда возникает из-за неполадок
на сайте ЕГАИС. Но это происходит крайне редко.

В основном ошибки при генерации связаны с некорректными настройками компьютера.

Что такое rsa?

RSA — одна из первых систем шифрования с открытым ключом, созданная в 1977 году. RSA был открыт Роном Ривестом, Ади Шамиром и Леонардом Адлеманом, чьи фамилии и составляют аббревиатуру RSA. Этот алгоритм разрабатывался долгое время, прежде чем нашел свое место.

Что такое dsa?

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

Dsa vs rsa: битва цифровых подписей

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

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

В чем разница между rsa и dsa?

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

Еще одним отличием DSA от RSA является скорость. Первое — это более быстрая подпись, а второе — более эффективная при проверке. Но поскольку аутентификация требует и того, и другого, расхождения в скорости могут быть не такими значительными, как кажется.

Кроме того, DSA работает только с более безопасным, вторым изданием сетевого протокола Secure Shell (SSH). RSA работает с SSH2, но также совместим с оригинальным SSH, который теперь считается неполноценным. Поэтому, если вас беспокоит случайное использование SSH, DSA может быть лучшим выбором.

Как видите, что различия между RSA и DSA довольно незначительны. Поэтому не стоит слишком беспокоиться о выборе между ними, к тому же с точки зрения совместимости они равны. RSA и DSA используются для одних и тех же интернет-протоколов и сертификатов, таких как Nettle, OpenSSL, wolfCrypt, Crypto и cryptlib.

Настройка jre

Казалось бы, все настроено, и должно работать. Но нет. Остается еще один важный штрих.

Чтобы из приложения на JBoss аутентифицироваться в КриптоПро УЦ по протоколу Gost TLS, сервер JBoss нужно запускать в JRE с установленным КриптоПро JCP провайдером.

При установке JCP в настройки JRE вносятся изменения. В частности, в jre1.8.0_144libsecurity java.security алгоритмы KeyManagerFactory и TrustManagerFactory меняются на Gost. Если так оставить, то в JBoss при старте будет возникать ошибка:

Настройка приложения

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

Домен безопасности и виртуальный хост приложения указываются в /WEB-INF/jboss-web.xml

Настройка сервера jboss

Для настройки сервера JBoss EAP 7.0.0 все изменения нужно внести в конфигурационный файл jboss-EAP-7.0.0standaloneconfiguration

standalone.xml

В раздел <system-properties> добавляются настройки, указывающие серверу, каких провайдера и хранилища использовать для двусторонней ГОСТ-аутентификации:

Для настройки RSA TLSv1.2 аутентификации пользователя и сервера JBoss в раздел

нужно добавить область безопасности:

Таким образом, для JBoss указаны все необходимые хранилища ключей и сертификатов.

В раздел

Номенклатура сертификатов

Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в

пищевой

цепочке доверия.

По степени

крутизны

дороговизны и надежности сертификаты делятся на 3 вида:

DVOVEV

Общие рекомендации для успешной генерации транспортного rsa ключа егаис

Для успешной генерации транспортных ключей на сайте ЕГАИС необходимо соблюсти некоторые требования и рекомендации:

Для настройки рабочего места для доступа личный кабинет ЕГАИС Вы можете воспользоваться нашей статьей.

Откуда берутся сертификаты?

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

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

   

2. Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
3. Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.

Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS < 1.2.

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem

Далее, создает CSR — запрос на подписание сертификата.

openssl req -new -sha256 -key private.key -out server.csr -days 730

И подписываем.

openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt

Результат можно посмотреть командой:

openssl x509 -text -noout -in public.crt

Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

openssl -help
openssl x509 -help
openssl s_client -help

Ровно то же самое можно сделать с помощью java утилиты keytool.

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Следует серия вопросов, чтобы было чем запомнить поля owner и issuer

What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?

Конвертируем связку ключей из проприетарного формата в PKCS12.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

Смотрим на результат:

Alias name: selfsigned
Creation date: 20.01.2021
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2021 until: Tue Jan 15 18:33:42 MSK 2021
Certificate fingerprints:
     MD5:  B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
     SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
     SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D

Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB   92 44 9D 95 47 94 E4 97  0.X..v...D..G...
0010: C8 1E F1 92                                        ....
]
]

Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.

subjectKeyIdentifier EXTENSION ::= {
    SYNTAX SubjectKeyIdentifier
    IDENTIFIED BY id-ce-subjectKeyIdentifier
}

SubjectKeyIdentifier ::= KeyIdentifier

Ошибка в методе createcertificaterequest error: ckr_attribute_type_invalid

Такая ошибка была нами зафиксирована при использовании ключа JaCarta SE.

Для исправления ошибки необходимо инициализировать раздел PKI на носителе. Для этого откройте Единый клиент JaCarta желательно включить интерфейс Администратора (снизу слева кнопка “Переключиться в режим администрирования”). Перейдите вверху во вкладку PKI и нажмите “Инициализировать”. При запросе пин-кода введите пин-код Администратора 00000000, пин-код Пользователя 11111111.

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

Также не забывайте о том, что для нормальной работы вашего защищенного носителя для ЕГАИС должен быть установлен свежий драйвер ключа!

Если Вы самостоятельно не можете справится с генерацией транспортного ключа ЕГАИС – 
обратитесь к нашим специалистам (достаточно просто написать в чат на сайте). Обычно мы справляемся с этой задачей за 5-15 минут.

Решения самых популярных проблем с ЕГАИС Вы можете найти в нашем
Telegram канале “ЕГАИС простыми словами” (@egais_is_easy).

Если помогла статья – можете сказать Спасибо автору:

Ошибка в методе createcertificaterequest error: ckr_pni_incorrect

В этой ошибке прямым текстом, правда по иностранному, написано, что неверно введен пин-код. 

Проверьте правильность ввода пин-кодов. Если на вашем носителе установлен пин-код по умолчанию. и Вы его не помните, то напоминаем:

• для JaCrata пин RSA – 11111111, пин ГОСТ – 0987654321
• для Рутокен пин RSA – 12345678, пин ГОСТ – 12345678

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

Если Вы самостоятельно не можете справится с пин-кодом для ключа ЕГАИС – обратитесь к нашим специалистам (достаточно просто написать в чат на сайте). Обычно мы справляемся с этой задачей за 5-15 минут.

Ошибка при генерации rsa ключа “выберете устройство чтения смарт карт…”

Если при генерации ключа ЕГАИС вместо окна запроса пин-кода Вы увидели окно “Выберете устройство чтения смарт карт” или “Обнаружена смарт-карта, но она не может использоваться для текущей операции…” или “Смарт-карта не может выполнить запрошенную операцию либо операция требует другой смарт-карты”, значит нужно скорректировать настройки компьютера.

Такая ошибка возникает из-за того, что настройки вашего компьютера не позволяют сформировать ключи, необходимые для работы УТМ ЕГАИС.

Если Вы используете носитель Рутокен ЭЦП, то вам необходимо сделать следующее:

Откройте Панель управления Рутокен (запускается ярлыком на рабочем столе или через меню Пуск – Программы (или Все программы) – Рутокен – Панель управления Рутокен), перейдите на вкладку “Настройки” и нажмите на кнопку “Настройка” в разделе “Настройки криптопровайдера”. Установите напротив строки Рутокен ЭЦП значение Microsoft Base Smart Card Crypto Provider.

Пробуйте сгенерировать транспортный ключ ЕГАИС еще раз.

Если не получилось – сделайте перенастройку еще раз. Выберете другой криптопровайдер, нажмите ОК, и снова выберете Microsoft Base Smart Card Crypto Provider.

Подготовка gost-ключей аутентификации

Процесс обоюдной аутентификации сервера JBoss и КриптоПро УЦ сервера в сущности такой же. Единственное отличие в криптографических алгоритмах.

Серверы обмениваются сертификатами с алгоритмами подписи ГОСТ Р 34.11/34.10-2001 и хэширования подписи ГОСТ Р 34.11-94 вместо применяемых в RSA TLSv1.2 sha256RSA и sha256 соответственно. В качестве корневого сертификата здесь выступает ROOT-сертификат самого ПАК КриптоПро УЦ.

Подготовка rsa-ключей аутентификации

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

Удостоверяющие центры для сервера и клиента могут быть разные.

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

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

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

Вот, например, хорошая статья и пошаговая инструкция по настройке Two-way SSL with TLS1.2 для Oracle SOA Suite с использованием openSSL и keytool. Но, правда, она частично потеряла актуальность и перестала отражать всю картину. Выпущенные по ней сертификаты не будут корректно восприниматься в веб-браузерах.

Error: «Subject Alternative Name Missing» or NET::ERR_CERT_COMMON_NAME_INVALID or «Your connection is not private»

если получит с сервера SSL-сертификат без домена в альтернативном имени субъекта сертификации.

Вот что говорит об этом Support Google Chrome Answer

Как с помощью openSSL добавить в сертификат subjectAlternativeName — можно посмотреть здесь и здесь

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

Постановка задачи

Для корпоративного приложения с тонким клиентом в веб-браузере, middle или backend servlet-а, которые запускаются на JBoss EAP, необходимо настроить двустороннюю аутентификацию по протоколу TLSv1.2 с применением зарубежных криптографических алгоритмов.

Задача усложняется тем, что приложение на сервере JBoss в свою очередь взаимодействует, например, с Программно-аппаратным комплексом «ПАК Удостоверяющий центр КриптоПро», где требуется процедура двусторонней аутентификации по протоколу Transport Layer Security (TLSv1.0) c использованием российских криптографических алгоритмов.

Получается, что в одном приложении на сервере JBoss нужно подружить отечественную и зарубежную криптографию.

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

Результаты

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

Словарный запас

Определение X.509 сертификатов есть в архиве ITU-T

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией.

Сценарий №1 — найти следующего в связке

Связка сертификатов — Объединение нескольких X.509 сертификатов в один файл, чаще всего в формате PEM. Связка передается по сети в момент протокола рукопожатия SSL/TLS.

Самый сок начинается, когда имеете дело со связкой сертификатов, a. k. a certificate chain. Часто просматривая лапшу в связке ключей jks непросто понять как найти родительский сертификат, когда там россыпь новых и старых сертификатов на несколько доменных имен.