Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline Евгений Афанасьев  
#11 Оставлено : 14 марта 2018 г. 13:10:04(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Судя по переписке в ЛС, решить проблему удалось (ответить может только сам автор поста).
Предположу, что вы используете ключ подписи (PrivateKey) для операции расшифрования, а не ключ обмена (ExchangeKey). Т.к. применяется согласование ключей и алгоритм GostTransport, то при вызове init() у Cipher проверяется, что ключ, который подали в setKEK(key) - ключ обмена. Эта ошибка, правда, поглощается внутри xmlsec, ее не увидать без включения логирования, например, так: -Djava.util.logging.config.file=log.properties
где log.properties содержит:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
handlers=java.util.logging.ConsoleHandler
.level=ALL
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
Тогда в логе может появиться строка вида: Original Exception was java.security.InvalidKeyException: Ключ подписи нельзя использоваться для этой операции.
Далее я использовал ключ обмена, но расшифровать, естественно, не удалось: получил ту же ошибку, т.к. нужен правильный ключ.
Также нужно сказать, что часто в коде xmlsec используется XMLCipher cipher = XMLCipher.getInstance(), т.е. без указания провайдера (его никак не передать извне). Поэтому можно вернуться к первому варианту, как в примере CryptXML из samples.jar, и использовать XMLCipher xmlCipher = XMLCipher.getInstance(), но при этом JCSP должен быть в списке java.security выше JCP, т.к. в таком случае провайдер для XMLCipher определяется по положению в списке.

Алгоритму urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 соответствует шифратор TransportCipher. TransportCipher вызывается самим xmlsec. Но TransportCipher принимает для расшифрования только ключа обмена (не ключ подписи). Пример зашифрования есть в CryptXML в samples.jar:
SecretKey sessionKey =
X509Certificate cert =
XMLCipher keyCipher = XMLCipher.getInstance(Consts.URI_GOST_TRANSPORT);
keyCipher.init(XMLCipher.WRAP_MODE, cert.getPublicKey()); // создается эфемерный ключ E, согласуется с открытым ключом получателя O, получаем ключ согласования A, на котором в дальнейшем будет зашифрован sessionKey. Эта структура KeyTransport потом будут помещена в EncryptedKey
EncryptedKey encryptedKey = keyCipher.encryptKey(doc, sessionKey);
encryptedKey.setKeyInfo(certKeyInfo);
Далее, согласно примеру, на сессионном ключе sessionKey выполняется шифрование данных, и данные помещаются в CipherValue.

Можно и обратно извлечь все узлы и выполнить работу, которую делает xmlsec, примерно так:
XMLCipher keyCipher = XMLCipher.getInstance(Consts.URI_GOST_TRANSPORT);
keyCipher.init(XMLCipher.UNWRAP_MODE, <private_key>); // будет снова выполнено согласование эфемерного ключа E из EncryptedKey с закрытым ключом P, на полученном ключе согласования A будет расшифрован сессионный ключ sessionKey. Только ключ обмена в private_key в init!
SecretKey sessionKey = keyCipher.decryptKey(<EncryptedKey>);
...
XMLCipher xmlCipher = XMLCipher.getInstance();
xmlCipher.init(XMLCipher.DECRYPT_MODE, null);
Element encryptedDataElement = (Element) doc.getElementsByTagNameNS(
EncryptionConstants.EncryptionSpecNS,
EncryptionConstants._TAG_ENCRYPTEDDATA).item(0);
if (key != null) xmlCipher.setKEK(sessionKey);
xmlCipher.doFinal(doc, encryptedDataElement); // расшифрование CipherValue на ключе sessionKey
Более точная реализация есть прямо в xmlsec.
Offline Ivan G. Zakirov  
#12 Оставлено : 14 марта 2018 г. 13:31:24(UTC)
Ivan G. Zakirov

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.03.2018(UTC)
Сообщений: 4
Мужчина
Российская Федерация

Автор: afev Перейти к цитате
Можно и обратно извлечь все узлы и выполнить работу


Работаю с C#. Пример шифрования и дешифровки брал из Crypto Pro .NET SDK "EncryptCerts.cs".
В методе:
Цитата:
// Получение ключа расшифрования
private static SymmetricAlgorithm GetDecryptionKey(EncryptedXml exml,
EncryptedData encryptedData)

Получение ключа дешифровки происходит из PrivateKey сертификата находящегося в локальном хранилище ПК.

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

PS: или в случае с ФСС надо как-то иначе добывать ключ дешифровки путем танцев с бубном из данных их публичного сертификата (как вы описали выше) которым они шифруют ? (на тек. момент с тестового сервиса приходит шифрованное сообщение их же публичным сертификатом от которого приватного ключа у нас быть не может естественно. Возможно это потому-что используем данные из тестового примера и шифрование происходит по сертификату прикрепленному по регистрационному номеру страхователя).
Offline PaulIsh  
#13 Оставлено : 4 апреля 2018 г. 7:28:19(UTC)
PaulIsh

Статус: Новичок

Группы: Участники
Зарегистрирован: 16.04.2013(UTC)
Сообщений: 8
Российская Федерация
Откуда: Красноярск

Добрый день.

Пытаемся повторить весь процесс на web используя http://gostcrypto.com/

Также столкнулись с неясностью алгоритма.
Как мы видим процесс:

1. Формируем UKM (случайные 8 байт)
2. Формируем KEK (ключ шифрования ключа) используя публичный ключ ФСС, наш закрытый ключ и UKM алгоритмом VKO GOST R 34.10-2001
3. Формируем CEK (ключ шифрования содержимого) для GOST 28147
4. Шифруем данные по GOST 28147
5. Шифруем ключ CEK используя KEK и UKM по GOST 28147-89 key wrap

Далее для XML сцепляем UKM и данные и переводим в base64, также в base64 переводим зашифрованный ключ.

ФСС нам выдает ошибку. Что мы делаем не так?
Offline Ivan G. Zakirov  
#14 Оставлено : 4 апреля 2018 г. 9:02:00(UTC)
Ivan G. Zakirov

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.03.2018(UTC)
Сообщений: 4
Мужчина
Российская Федерация

Автор: PaulIsh Перейти к цитате
Добрый день.

Пытаемся повторить весь процесс на web используя http://gostcrypto.com/

Также столкнулись с неясностью алгоритма.
Как мы видим процесс:

1. Формируем UKM (случайные 8 байт)
2. Формируем KEK (ключ шифрования ключа) используя публичный ключ ФСС, наш закрытый ключ и UKM алгоритмом VKO GOST R 34.10-2001
3. Формируем CEK (ключ шифрования содержимого) для GOST 28147
4. Шифруем данные по GOST 28147
5. Шифруем ключ CEK используя KEK и UKM по GOST 28147-89 key wrap

Далее для XML сцепляем UKM и данные и переводим в base64, также в base64 переводим зашифрованный ключ.

ФСС нам выдает ошибку. Что мы делаем не так?


Да проблему решил и алгоритм работает на тестовом контуре в двух вариантах с шифрованием и без.
Основные проблемы возникавшие - это отступление от шаблона (XML документа) указанного в спецификации (упущено явное указание простраства имен тэгов, изменен порядок следования узлов, упущена замена стандартной информации сформированной на требуемую по спецификации). Могу лишь описать как на C# выполнялось, основа подхода работы бралась из примера "C:\Program Files\Crypto Pro\.NET SDK\Examples\simple.zip\Xml\cs\EncryptCerts.cs":
1. Создаем XML документ соответствующий структуре по спецификации п.4.4.
2. Накладываем ЭЦП на содержимое узла "<soapenv:Body wsu:Id="REGNO_#########">. Пришлось использовать измененный SignedXml по причине наличия требования в спецификации явных пространств имен, пример есть на "http://cryptopro.ru/blog/2012/05/16/podpis-soobshchenii-soap-dlya-smev-s-ispolzovaniem-kriptopro-net", а стандартный SignedXml не умеет подписывать с пространством имен, что приводило либо к ошибкам, либо не соответствие подписи и содержимого.
2.1. Результат работы ЭЦП -> содрежимое узлов "wsse:BinarySecurityToken", "SignatureValue", "SignedInfo" и в общем всего что необходимо по спецификации -> добавляем в документ из (п.1). Это необходимо по причине того (возможно только в C#), что созданный XML блок в результате подписи не соответствует требуемой по спецификации ФСС структуре XML.
3. Шифрование.
3.1. Создаем документ XML соответствующий структуре по спецификации (п.5.1..) Обратим внимание что в спецификации есть "косяк" с тэгами узлов "<soapenv:Body>" и "</SOAP-ENV:Body>". Мы использовали соответствие общей структруе "<soapenv:Body>" а зашифрованная структура "</xenc:EncryptedData>" содержалась внутри "<soapenv:Body>".
3.2. Конечный документ из (п.2.) шифруем.
3.2.1. Получаем (X509Certificate2) публичную часть сертификата получателя (ФСС тестовый контур) из хранилища на локальном ПК.
3.2.2. Используя шифровщик XML "EncryptedXml" создаем блок зашифрованных данных "EncryptedData" (EncryptedData EncryptedData = EncryptedXml.Encrypt(XmlElement, CertificateEncrypt);). В качестве XmlElement указывался "<soapenv:Body>" из конечного документа из (п.2.).
3.2.3. Для EncryptedData указываем свойства: Type = "CryptoAlgoritm.GOST28147_89" (берется из библиотеки CryptoPro), EncryptionMethod = new EncryptionMethod(CPEncryptedXml.XmlEncGost28147Url)
3.2.4. Получаем результирующий XML зашифрованных данных из EncryptedData (XmlElement EncryptedElement = EncryptedData.GetXml();).
3.3. Опять из-за разницы требований спецификации и результатов полученных шифрованием, данные из (п.3.2.4.) подставляем в соответствующие тэги созданные в документе в (п.3.1.) и получаем итоговый зашифрованный документ готовый к отправке (пример XSLT шаблона для трансформации на C#):

4. По требованию спецификации необходимо в отправляемом сообщении указать свой публичный сертификат, поэтому заменяем информацию сертификата в узле "/soapenv:Envelope/soapenv:Body/xenc:EncryptedData/ds:KeyInfo/xenc:EncryptedKey/ds:KeyInfo/ds:X509Data/ds:X509Certificate" на свой сертификат (им будет шифроваться ответ от сервера), остальную часть "xenc:EncryptedData" не трогаем.

PS (касаемо C#): никаких самостоятельных формирований ключа и т.п. не производили(все необходимые ключи есть в сертификате), все выполнялось стандартными средствами криптографии и подключенными библиотеками CryptoPro:
using CryptoPro.Sharpei;
using CryptoPro.Sharpei.Xml;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Security.Cryptography.Xml;

Отредактировано пользователем 4 апреля 2018 г. 9:27:23(UTC)  | Причина: Выделение основных проблем.

Offline arte-tkolomiets  
#15 Оставлено : 15 июня 2018 г. 15:04:16(UTC)
arte-tkolomiets

Статус: Участник

Группы: Участники
Зарегистрирован: 27.09.2016(UTC)
Сообщений: 16
Российская Федерация
Откуда: Краснодар

Поблагодарили: 4 раз в 1 постах
Приветствую, коллеги.
Не можете дать мне актуальное на данный момент шифрованное сообщение в ФСС на которое оно выдает ответ? В Xml-формате, конечно.
https://docs-test.fss.ru/WSLnCryptoV11 - для этого сервиса? Чобы я мог его исследовать немного на предмет внутренее кухни ФСС.
Дело в том, что мне нужно использовать низкоуровневое API на данный момент, да еще на делфи. Не могу пока преодолеть момент. Нужно понять, каие структуры шифрования, алгортмы, ФСС принимает на вход.
Первичный код вроде написан по мотивам темы
https://www.cryptopro.ru...osts&t=13688&p=2
но пока результат нулевой - отбрасывает просто все.

Отредактировано пользователем 15 июня 2018 г. 15:06:13(UTC)  | Причина: Не указана

Offline Михаил К.  
#16 Оставлено : 27 сентября 2019 г. 10:09:16(UTC)
Михаил К.

Статус: Участник

Группы: Участники
Зарегистрирован: 16.08.2017(UTC)
Сообщений: 19
Мужчина
Российская Федерация
Откуда: Санкт-Петербург

Сказал «Спасибо»: 2 раз
Автор: Ivan G. Zakirov Перейти к цитате
Автор: PaulIsh Перейти к цитате
Добрый день.

Пытаемся повторить весь процесс на web используя http://gostcrypto.com/

Также столкнулись с неясностью алгоритма.
Как мы видим процесс:

1. Формируем UKM (случайные 8 байт)
2. Формируем KEK (ключ шифрования ключа) используя публичный ключ ФСС, наш закрытый ключ и UKM алгоритмом VKO GOST R 34.10-2001
3. Формируем CEK (ключ шифрования содержимого) для GOST 28147
4. Шифруем данные по GOST 28147
5. Шифруем ключ CEK используя KEK и UKM по GOST 28147-89 key wrap

Далее для XML сцепляем UKM и данные и переводим в base64, также в base64 переводим зашифрованный ключ.

ФСС нам выдает ошибку. Что мы делаем не так?


Да проблему решил и алгоритм работает на тестовом контуре в двух вариантах с шифрованием и без.
Основные проблемы возникавшие - это отступление от шаблона (XML документа) указанного в спецификации (упущено явное указание простраства имен тэгов, изменен порядок следования узлов, упущена замена стандартной информации сформированной на требуемую по спецификации). Могу лишь описать как на C# выполнялось, основа подхода работы бралась из примера "C:\Program Files\Crypto Pro\.NET SDK\Examples\simple.zip\Xml\cs\EncryptCerts.cs":
1. Создаем XML документ соответствующий структуре по спецификации п.4.4.
2. Накладываем ЭЦП на содержимое узла "<soapenv:Body wsu:Id="REGNO_#########">. Пришлось использовать измененный SignedXml по причине наличия требования в спецификации явных пространств имен, пример есть на "http://cryptopro.ru/blog/2012/05/16/podpis-soobshchenii-soap-dlya-smev-s-ispolzovaniem-kriptopro-net", а стандартный SignedXml не умеет подписывать с пространством имен, что приводило либо к ошибкам, либо не соответствие подписи и содержимого.
2.1. Результат работы ЭЦП -> содрежимое узлов "wsse:BinarySecurityToken", "SignatureValue", "SignedInfo" и в общем всего что необходимо по спецификации -> добавляем в документ из (п.1). Это необходимо по причине того (возможно только в C#), что созданный XML блок в результате подписи не соответствует требуемой по спецификации ФСС структуре XML.
3. Шифрование.
3.1. Создаем документ XML соответствующий структуре по спецификации (п.5.1..) Обратим внимание что в спецификации есть "косяк" с тэгами узлов "<soapenv:Body>" и "</SOAP-ENV:Body>". Мы использовали соответствие общей структруе "<soapenv:Body>" а зашифрованная структура "</xenc:EncryptedData>" содержалась внутри "<soapenv:Body>".
3.2. Конечный документ из (п.2.) шифруем.
3.2.1. Получаем (X509Certificate2) публичную часть сертификата получателя (ФСС тестовый контур) из хранилища на локальном ПК.
3.2.2. Используя шифровщик XML "EncryptedXml" создаем блок зашифрованных данных "EncryptedData" (EncryptedData EncryptedData = EncryptedXml.Encrypt(XmlElement, CertificateEncrypt);). В качестве XmlElement указывался "<soapenv:Body>" из конечного документа из (п.2.).
3.2.3. Для EncryptedData указываем свойства: Type = "CryptoAlgoritm.GOST28147_89" (берется из библиотеки CryptoPro), EncryptionMethod = new EncryptionMethod(CPEncryptedXml.XmlEncGost28147Url)
3.2.4. Получаем результирующий XML зашифрованных данных из EncryptedData (XmlElement EncryptedElement = EncryptedData.GetXml();).
3.3. Опять из-за разницы требований спецификации и результатов полученных шифрованием, данные из (п.3.2.4.) подставляем в соответствующие тэги созданные в документе в (п.3.1.) и получаем итоговый зашифрованный документ готовый к отправке (пример XSLT шаблона для трансформации на C#):

4. По требованию спецификации необходимо в отправляемом сообщении указать свой публичный сертификат, поэтому заменяем информацию сертификата в узле "/soapenv:Envelope/soapenv:Body/xenc:EncryptedData/ds:KeyInfo/xenc:EncryptedKey/ds:KeyInfo/ds:X509Data/ds:X509Certificate" на свой сертификат (им будет шифроваться ответ от сервера), остальную часть "xenc:EncryptedData" не трогаем.

PS (касаемо C#): никаких самостоятельных формирований ключа и т.п. не производили(все необходимые ключи есть в сертификате), все выполнялось стандартными средствами криптографии и подключенными библиотеками CryptoPro:
using CryptoPro.Sharpei;
using CryptoPro.Sharpei.Xml;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Security.Cryptography.Xml;


Добрый день.
А сейчас все так же работает при наличии сертифицированных ключей от сертифицированного УЦ? Или все-таки надо теперь формировать эфемерный ключ? И нет ли у вас контактов в ФСС по технической части?
Offline two_oceans  
#17 Оставлено : 27 сентября 2019 г. 12:57:03(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
О как, еще одну старую тему про ФСС вытащили. Напочитать, в том числе с примерами:
https://www.cryptopro.ru...aspx?g=posts&t=16790 (PHP/Браузер плагин)
https://www.cryptopro.ru...aspx?g=posts&t=15341
https://www.cryptopro.ru...aspx?g=posts&t=13688 (низкоуровневые функции подробно как и что делать, Delphi)
https://www.cryptopro.ru...aspx?g=posts&t=16674 (Джава, выяснение всех подробностей)
https://www.cryptopro.ru...aspx?g=posts&t=16514 (Джава, параметры для шифрования)

Сейчас все также - есть "высокоуровневые" функции, которым просто передаете данные, несколько параметров и сертификаты, они там внутри формируют сессионный ключ, ключ согласования, шифруют данные сессионным ключом, шифруют сессионный ключ и в итоге выдают CMS или XML структуру с зашифрованными данными. Есть даже те, которые сами ставят правильный сертификат и заменять ничего не нужно.
Параллельно есть "низкоуровневые" функции, которыми все делаете почти "вручную" каждую операцию, генерируете ключи, шифруете и так далее.
Из новшеств нужно отметить, что при генерации ключа использования для сертификатов гост-2012 нужно установить параметры шифрования ТК 26 Z и использовать PRO_EXPORT c гост-2012 вместо PRO12_EXPORT.

Отредактировано пользователем 27 сентября 2019 г. 12:58:56(UTC)  | Причина: Не указана

Offline Ivan G. Zakirov  
#18 Оставлено : 27 сентября 2019 г. 19:09:33(UTC)
Ivan G. Zakirov

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.03.2018(UTC)
Сообщений: 4
Мужчина
Российская Федерация

Автор: Михаил К. Перейти к цитате

А сейчас все так же работает при наличии сертифицированных ключей от сертифицированного УЦ? Или все-таки надо теперь формировать эфемерный ключ? И нет ли у вас контактов в ФСС по технической части?


Если переходить на ГОСТ2012, то да надо генерировать сессионный ключ. Лучше скачайте CryptoPro .Net SDK - там есть примеры, по которым шифрование с ФСС подойдет (как пример называется не помню, но там в цикле шифрование для нескольких сертификатов). Перевести С# на Java наверно не составит труда особого.

По поводу контактов с ФСС - это вам надо выходить на ваше региональное отделение ФСС и они будут при необходимости уточнять технические части по своей внутренней линии тех.поддержки.

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

Отредактировано пользователем 27 сентября 2019 г. 19:11:18(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.