Статус: Активный участник
Группы: Участники
Зарегистрирован: 30.01.2019(UTC) Сообщений: 43  Откуда: Москва Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
|
Автор: two_oceans  Автор: migel Не подтверждается (модификацией трансформа смыва)
тестовый прогон с collapse поведением - то есть заменой [0x10,0x13]->0x20
и уборкой лидирующих/завершающих пробелов
документ не валидируется Там еще и замена подряд идущих на один пробел. Мне кажется что может быть проблема с порядком действий, трансформ смэва выполняется после каноникализации, то есть до него тем более 13 не дойдут. Вообще я предполагаю, что смэв валидирует через Джаву с применением КриптоПро, то есть чем гадать все варианты можно как первое приближение посмотреть поведение адаптера на Джаве. Я тоже попробую варианты на тестовой форме смэв 3. В общем добил  Collapse тоже не по канону последовательности WS не схлопываются в один пробел (0x20) Исходный документ  z1.xml (7kb) загружен 10 раз(а). результат подписи signed_z1.xml (9kb) загружен 13 раз(а).достигается заменой один 0xa на один пробел (и да никаких сверток пробельных символов) и пропуском символов 0xD вообще Отредактировано пользователем 6 февраля 2020 г. 14:11:59(UTC)
| Причина: Добавил требование пропуска 0xD
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Все равно что-то не так. Предположим 10 и 13 в виде ссылки (
 и 
) обрабатываются однаково и заменяются на один пробел, тогда замена одного на другой не изменит хэша и подпись будет верна. Однако если в форме ввести тот же текст, но заменить A на D - ЭЦП становится неверной. Поэтому 13 обрабатывается отлично от 10. А вот замена A на 9 проходит без последствий. И 
 на пробел тоже. О еще и пропуск 13 добавился. Значит их можно навставлять целую тучу. Забавно. Правда маковские концы строк это вроде как раз 13. Отредактировано пользователем 6 февраля 2020 г. 14:26:09(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 30.01.2019(UTC) Сообщений: 43 Откуда: Москва Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
|
Автор: two_oceans
О еще и пропуск 13 добавился.
Кристобаль Хозевич успел первым (ц) 
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 07.08.2019(UTC) Сообщений: 4 Сказал(а) «Спасибо»: 1 раз
|
Здравствуйте. Подписываю сообщение SendRequestRequest и оно успешно проходит проверку на https://smev3.gosuslugi.ru/portal/checkxmlform.jspЭП-ОВ подтверждена ЭЦП подтвержденаПодставляю другой вид сведений и получаю: ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП ЭЦП подтвержденаТ.е. заметьте "ЭЦП подтверждена", но есть проблема с ЭП-ОВ, которая отвечает за весь контверт, в отличии от ЭП-СП, которая отвечает как раз за элемент в видом сведений(!), который был изменен. Поэтому пока что впал в ступор, куда смотреть. Обратил внимание, что в проблемном виде сведений нет Id, а есть ИдЗапрос, который код не видит, а потому потом возникает пустой <Reference URI=""> (или так может быть?) Но в МР написано: "С помощью ЭП-СП подписывается элемент, находящийся в //MessagePrimaryContent (между открывающим и закрывающим тегами), имеющий атрибут Id" т.е. речь только про Id Если же все-таки вместо Id искать ИдЗапрос, то потом возникает ошибка "Неверное сформирована ссылка" и подпись не вычисляется вообще. Стоит ли решать эту проблему или это ошибочная ветка рассуждений? Ведь вообще о проблеме с ЭП-СП не написано, а влияет ли это как-то на ЭП-ОВ непонятно. Пакеты прикрепил. Буду рад любым советам и мыслям. 1 EhP-OV podtverzhdena, EhCP podtverzhdena.xml (11kb) загружен 14 раз(а). 2 EhP-OV ne podtverzhdena Oshibka proverki EhP Narushena celostnost' EhP. EhCP podtverzhdena.xml (10kb) загружен 6 раз(а).
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Добрый день! Ветка, полагаю, верная - удобно, когда все по СМЭВ 3 в одной теме. ЭП-СП находится внутри тега, подписываемого ЭП-ОВ и не удаляется перед подписанием ЭП-ОВ (по крайней мере, если нет трансформа enveloped-signature), поэтому косвенное влияние готовой ЭП-СП на процесс подписания и проверки ЭП-ОВ есть. Важно, что ЭП-СП подписывается раньше ЭП-ОВ. Ошибка может возникать, наоборот, в случае, когда подписали ЭП-ОВ, а потом пытаетесь подписать ЭП-СП (это нарушит ЭП-ОВ). Файлы посмотрю, отпишу. UPD. Посмотрел, пока причину не вижу, но у Вас используется трансформ enveloped-signature и хэш sha1. Трансформ имеет разночтения как его применять в случае когда подпись 1 от фрагмента 1 вложена во фрагмент 2, подписываемый подписью 2. Из-за этих разночтений не могу гарантировать, что порекомендую о трансформе правильно, я работаю без трансформа и подпись 1 остается при расчете хэша трансформа 2. Для Signature Algorithm указана схема гост-2012, поэтому для Digest Algorithm нужен тоже хэш гост-2012, а не sha1. Отредактировано пользователем 19 марта 2020 г. 11:35:33(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 07.08.2019(UTC) Сообщений: 4 Сказал(а) «Спасибо»: 1 раз
|
Автор: two_oceans Для Signature Algorithm указана схема гост-2012, поэтому для Digest Algorithm нужен тоже хэш гост-2012, а не sha1. Спасибо. Это поправил. Теперь <DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" /> вместо <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> Но это и не помогло и не помешало (не сломало рабочий вида сведений) Продолжим. Была ошибка при расчете подписи "Неверно сформированный элемент reference" Имеется в виду пустой <Reference URI=""> т.к. GetIdElement не нашел элемент по аттрибуту Id="AC439881-E925-771B-E040-A8C062C84DEE" Решение приводили однако даже где-то выше в этом топике. Я унаследовал класс SignedXmlEx от SignedXml и переопределил GetIdElement, чтоб искал по аттрибуту ИдЗапрос="AC439881-E925-771B-E040-A8C062C84DEE" Код: public override XmlElement GetIdElement(XmlDocument doc, string id)
{
XmlElement idElem = base.GetIdElement(doc, id);
if (idElem == null)
{
idElem = doc.SelectSingleNode("//*[@ИдЗапрос=\"" + id + "\"]") as XmlElement;
}
return idElem;
}
Теперь URI заполнился <Reference URI="#AC439881-E925-771B-E040-A8C062C84DEE"> Подпись посчиталась. Но при проверке на https://smev3.gosuslugi.ru/portal/checkxmlform.jsp вот такая беда: ЭЦП не подтверждена: #AC439881-E925-771B-E040-A8C062C84DEE org.apache.xml.security.signature.MissingResourceFailureException: The Reference for URI #AC439881-E925-771B-E040-A8C062C84DEE has no XMLSignatureInput Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE Original Exception was org.apache.xml.security.utils.resolver.ResourceResolverException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE ЭЦП подтверждена Ощущение, что я у себя-то поправил, а они не в курсе) Суть в том, что в предыдущих решениях проблемы "Неверно сформированный элемент reference" переопределение GetIdElement давало поиск все того же Id (там решались проблемы с неймспейсами) А про ИдЗапрос или другие альтернативы Id я ничего не нашел. Как-то это старнно. Что дальше делать пока не знаю. Подписанный запрос прикрепил. 3.xml (10kb) загружен 3 раз(а).
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: AntonChik Спасибо. Пожалуйста. Автор: AntonChik Была ошибка при расчете подписи "Неверно сформированный элемент reference"
Имеется в виду пустой <Reference URI=""> т.к. GetIdElement не нашел элемент по аттрибуту Id="AC439881-E925-771B-E040-A8C062C84DEE" Если URI пустая строка на расчет хэша должен подаваться весь документ, поэтому немного сама по себе проверка должна срабатывать, но возможно не будет расценено как ЭП-ОВ верного фрагмента. Автор: AntonChik Решение приводили однако даже где-то выше в этом топике.
Я унаследовал класс SignedXmlEx от SignedXml и переопределил GetIdElement, чтоб искал по аттрибуту ИдЗапрос="AC439881-E925-771B-E040-A8C062C84DEE"
...
Ощущение, что я у себя-то поправил, а они не в курсе) Именно так. Нельзя просто взять с потолка какой-то атрибут и назначить его вместо Id, как минимум у атрибута должен быть тип xs:ID (это надо смотреть в схеме xsd для пространства urn://x-artefacts-fns-inn-singular/root/270-18/4.0.1). Если атрибут ИдЗапрос имеет такой тип, то его можно выбрать вместо Id (тогда это недоработка проверки по стандарту), если тип ИдЗапрос другой то надо добавить атрибут с типом xs:ID, например, тот самый Id из пространства по умолчанию (если пространство имен его разрешает) или wsu:Id (и определение префикса wsu, если разрешены другие пространства имен) либо оставить URI="" и выбрать фрагмент через XPath трансформ (я бы не рекомендовал для СМЭВ, но в сценарии для этого конкретного вида сведений https://smev3.gosuslugi....p;page=1&dTest=false почему именно он, с примерами как выбрать фрагмент по XPath по значению ИдЗапрос). Автор: AntonChik Суть в том, что в предыдущих решениях проблемы "Неверно сформированный элемент reference" переопределение GetIdElement давало поиск все того же Id (там решались проблемы с неймспейсами) А про ИдЗапрос или другие альтернативы Id я ничего не нашел. Как-то это старнно. Что дальше делать пока не знаю. Подписанный запрос прикрепил. 3.xml (10kb) загружен 3 раз(а). Посмотрю файл, отпишу. UPD. В первой подписи предсказуемо не находится подписанный фрагмент. Само значение подписи проверяется успешно, то есть хэш SignedInfo, сертификат в порядке. Во второй подписи у меня срабатывает enveloped-signature и удаляет первую, хэш не сходится. Само значение подписи проверяется успешно, то есть хэш SignedInfo, сертификат в порядке. К слову, отметил 2 момента: 1) 3.xml не в кодировке UTF-8, перекодировал; 2) у обоих подписей одинаковый Id - нехорошо. Для базовой xmldsig разницы нет (только документ невалидный), но с xades форматами это может вызвать проблемы создания/проверки подписи. Отредактировано пользователем 20 марта 2020 г. 10:07:09(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 07.08.2019(UTC) Сообщений: 4 Сказал(а) «Спасибо»: 1 раз
|
Автор: two_oceans Нельзя просто взять с потолка какой-то атрибут и назначить его вместо Id Да, затея изначально казалась сомнительной. Опять же ссылаясь на МР Цитата:По требованиям поставщика сведений подпись ЭП-СП может быть обязательной для подписи блока сведений по форматам поставщика. пока буду считать, что подпись в данном случае не является обязательной. Полностью убрал подпись элемента вида услуг. Теперь проверка выдает просто: "ЭЦП подтверждена" Буду пробовать отправлять запрос в тестовую среду.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 24.11.2015(UTC) Сообщений: 1
|
Коллеги, добрый день.
Имеется вопрос по сертификации CryptoPro .NET SDK компонентов ФСБ.
Правильно ли я понимаю, что (для работы со СМЭВ 3.х) такая сертификация не требуется, так как CryptoPro .NET прадставляет из себя интерфейс к стертифицированному СКЗИ CryptoPro CSP?
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 30.06.2020(UTC)
Сообщений: 2
|
Здравствуйте, коллеги! Стоит задача по переводу подписания запросов для СМЭВ3 с ПО Validata на ПО КриптоПро под .Net. Подпись должна осуществляется по алгоритму ГОСТ 34.10-2012 Функционал на валидате рабочий. Валидата не подписывает xml целиком, а отдельно считает хэш по ГОСТ 34.11-2012 и подписывает его по ГОСТ 34.10-2012. Собственно эти части и нужно перевести на криптопро. Код:
//inputBytes - это уже каноничный и трансформированный вид сообщения
var inputBytes = System.Text.Encoding.UTF8.GetBytes(xmlSignedInfoCanon);
// Создаем объект для хэширования.
HashAlgorithm myhash = HashAlgorithm.Create("GOST3411");
// Вычисляем хэш от всех прочитанных данных. Хэш считается верно и совпадает с решением на валидате.
byte[] hashValue = myhash.ComputeHash(inputBytes);
// Инициализация крипто-провайдера
Gost3410_2012_256CryptoServiceProvider Gost = (Gost3410_2012_256CryptoServiceProvider)MyCertificate.PrivateKey;
// Подписываем хэш
byte[] signedInfoHashData = Gost.SignHash(hashValue);
Сертификат выпущен тестовым УЦ КриптоПро. Скрин сертификатаПолучаю ошибку "ЭП-ОВ не подтверждена: #SIGNED_BY_CONSUMER Ошибка проверки ЭП: Нарушена целостность ЭП" Подозреваю, что что-то не так делаю.. но не пойму куда копать
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
