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

Уведомление

Icon
Error

9 Страницы«<789
Опции
К последнему сообщению К первому непрочитанному
Offline migel  
#161 Оставлено : 6 февраля 2020 г. 13:46:12(UTC)
migel

Статус: Активный участник

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Автор: migel Перейти к цитате
Не подтверждается (модификацией трансформа смыва)
тестовый прогон с collapse поведением - то есть заменой [0x10,0x13]->0x20
и уборкой лидирующих/завершающих пробелов
документ не валидируется
Там еще и замена подряд идущих на один пробел. Мне кажется что может быть проблема с порядком действий, трансформ смэва выполняется после каноникализации, то есть до него тем более 13 не дойдут. Вообще я предполагаю, что смэв валидирует через Джаву с применением КриптоПро, то есть чем гадать все варианты можно как первое приближение посмотреть поведение адаптера на Джаве. Я тоже попробую варианты на тестовой форме смэв 3.


В общем добил Brick wall
Collapse тоже не по канону последовательности WS не схлопываются в один пробел (0x20)
Исходный документ
z1.xml (7kb) загружен 3 раз(а).
результат подписи
signed_z1.xml (9kb) загружен 6 раз(а).

достигается заменой один 0xa на один пробел (и да никаких сверток пробельных символов)
и пропуском символов 0xD вообще

Отредактировано пользователем 6 февраля 2020 г. 14:11:59(UTC)  | Причина: Добавил требование пропуска 0xD

Offline two_oceans  
#162 Оставлено : 6 февраля 2020 г. 14:17:18(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 221 раз в 207 постах
Все равно что-то не так. Предположим 10 и 13 в виде ссылки (&#xA; и &#xD;) обрабатываются однаково и заменяются на один пробел, тогда замена одного на другой не изменит хэша и подпись будет верна. Однако если в форме ввести тот же текст, но заменить A на D - ЭЦП становится неверной. Поэтому 13 обрабатывается отлично от 10.

А вот замена A на 9 проходит без последствий. И &#xA; на пробел тоже.

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

Отредактировано пользователем 6 февраля 2020 г. 14:26:09(UTC)  | Причина: Не указана

Offline migel  
#163 Оставлено : 6 февраля 2020 г. 14:27:20(UTC)
migel

Статус: Активный участник

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате

О еще и пропуск 13 добавился.

Кристобаль Хозевич успел первым (ц) Dancing

Offline AntonChik  
#164 Оставлено : 19 марта 2020 г. 7:43:27(UTC)
AntonChik

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

Группы: Участники
Зарегистрирован: 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) загружен 2 раз(а). 2 EhP-OV ne podtverzhdena Oshibka proverki EhP Narushena celostnost' EhP. EhCP podtverzhdena.xml (10kb) загружен 1 раз(а).
Offline two_oceans  
#165 Оставлено : 19 марта 2020 г. 10:16:08(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 221 раз в 207 постах
Добрый день!
Ветка, полагаю, верная - удобно, когда все по СМЭВ 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)  | Причина: Не указана

Offline AntonChik  
#166 Оставлено : 19 марта 2020 г. 14:16:02(UTC)
AntonChik

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

Группы: Участники
Зарегистрирован: 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) загружен 2 раз(а).


Offline two_oceans  
#167 Оставлено : 20 марта 2020 г. 5:33:16(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 221 раз в 207 постах
Автор: 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) загружен 2 раз(а).
Посмотрю файл, отпишу.

UPD. В первой подписи предсказуемо не находится подписанный фрагмент. Само значение подписи проверяется успешно, то есть хэш SignedInfo, сертификат в порядке.
Во второй подписи у меня срабатывает enveloped-signature и удаляет первую, хэш не сходится. Само значение подписи проверяется успешно, то есть хэш SignedInfo, сертификат в порядке.

К слову, отметил 2 момента: 1) 3.xml не в кодировке UTF-8, перекодировал; 2) у обоих подписей одинаковый Id - нехорошо. Для базовой xmldsig разницы нет (только документ невалидный), но с xades форматами это может вызвать проблемы создания/проверки подписи.

Отредактировано пользователем 20 марта 2020 г. 10:07:09(UTC)  | Причина: Не указана

Offline AntonChik  
#168 Оставлено : 20 марта 2020 г. 6:11:26(UTC)
AntonChik

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

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

Сказал(а) «Спасибо»: 1 раз
Автор: two_oceans Перейти к цитате
Нельзя просто взять с потолка какой-то атрибут и назначить его вместо Id

Да, затея изначально казалась сомнительной.

Опять же ссылаясь на МР
Цитата:
По требованиям поставщика сведений подпись ЭП-СП может быть обязательной для подписи блока сведений по форматам поставщика.

пока буду считать, что подпись в данном случае не является обязательной.

Полностью убрал подпись элемента вида услуг.
Теперь проверка выдает просто:
"ЭЦП подтверждена"

Буду пробовать отправлять запрос в тестовую среду.



Offline just.skorik  
#169 Оставлено : 18 мая 2020 г. 12:15:22(UTC)
just.skorik

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

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

Коллеги, добрый день.
Имеется вопрос по сертификации CryptoPro .NET SDK компонентов ФСБ.
Правильно ли я понимаю, что (для работы со СМЭВ 3.х) такая сертификация не требуется, так как CryptoPro .NET прадставляет из себя интерфейс к стертифицированному СКЗИ CryptoPro CSP?
Offline Tolmasov  
#170 Оставлено : 3 июля 2020 г. 21:05:22(UTC)
Tolmasov

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

Группы: Участники
Зарегистрирован: 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 Ошибка проверки ЭП: Нарушена целостность ЭП"

Подозреваю, что что-то не так делаю.. но не пойму куда копать
Offline Александр Лавник  
#171 Оставлено : 4 июля 2020 г. 16:43:54(UTC)
Александр Лавник

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

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

Сказал «Спасибо»: 30 раз
Поблагодарили: 451 раз в 432 постах
Автор: Tolmasov Перейти к цитате
Здравствуйте, коллеги!

Стоит задача по переводу подписания запросов для СМЭВ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 Ошибка проверки ЭП: Нарушена целостность ЭП"

Подозреваю, что что-то не так делаю.. но не пойму куда копать

Здравствуйте.

Попробуйте побайтово перевернуть полученную подпись.
Техническую поддержку оказываем тут
Наша база знаний
Offline Tolmasov  
#172 Оставлено : 4 июля 2020 г. 19:47:28(UTC)
Tolmasov

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

Группы: Участники
Зарегистрирован: 30.06.2020(UTC)
Сообщений: 2

Цитата:
Попробуйте побайтово перевернуть полученную подпись.


Если я правильно понял, то представил байтовый массив в обратном порядке. Не помогло, ошибка та же.
Подпись:
Convert.ToBase64String(signedInfoHashData)
"KPBTk0b86091PMXvpYZpmxy9PVApG3HAx/DpgUZjeOeKdgkeQJgHSGm3U6Y+No763P3NrWHwieF3oxhJTag2kw=="

Перевернул:
Convert.ToBase64String(signedInfoHashDataRevers)
"kzaoTUkYo3fhifBhrc393PqONj6mU7dpSAeYQB4JdorneGNGgenwx8BxGylQPb0cm2mGpe/FPHVP6/xGk1PwKA=="

Причем проверка подписанного хэша проходит проверку успешно.
Перевернутую подпись сам провайдер криптопро считает не верным.
Код:
Gost.VerifySignature(hashValue, signedInfoHashData); //true


Код:
Gost.VerifySignature(hashValue, signedInfoHashDataRevers); //false


Однако если проверяю подпись уже всего подписанного xml
Код:

SignedXml signedXml = new SignedXml(xmlDocument);
signedXml.SafeCanonicalizationMethods.Add("urn://smev-gov-ru/xmldsig/transform");
bool resultsing = signedXml.CheckSignature(); //false




Может портал СМЭВ не валидировать подпись, если подписываю сертификатом выданным тестовым УЦ КриптоПро?

Отредактировано пользователем 4 июля 2020 г. 20:29:02(UTC)  | Причина: Не указана

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