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

Уведомление

Icon
Error

9 Страницы«<34567>»
Опции
К последнему сообщению К первому непрочитанному
Offline Boris@Serezhkin.com  
#41 Оставлено : 27 мая 2015 г. 11:21:18(UTC)
Boris@Serezhkin.com

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

Группы: Участники
Зарегистрирован: 26.08.2010(UTC)
Сообщений: 259
Откуда: Moscow

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
SMEV-100003 и философия

Разбираясь, что я делаю не так наткнулся на документ: "Коды ошибок СМЭВ.pdf"
А в нем написано: SMEV-100003  SMEV-200003 Неверная ЭП сообщения

Проверка сообщения с помоью функционала на ТП СМЭВ "Инструменты разработки сервисов"
http://smev.gosuslugi.ru/portal/services-tools.jsp
Сходил туда, подсунул для проверки свой запрос,
получил: Ошибка разбора XML сообщения [Content is not allowed in prolog.]
Круто, но неинформативно.

О возможных ошибках возникновения SMEV-100003 написано:
1. Содержимое подписываемого тега изменено после подписания.
-А какого тега? Как я понимаю речь идет о <ds:Reference URI="#body"> Не менял, клянусь!

2. Используемые ОИВом библиотеки инвертируют подпись.
В этом случае необходимо побитово инвертировать подпись перед внесением в XML.
-Т.е. при расчете я, как ОИВ, (ух какие высоты, я и Орган Испонительной власти)
получаю инвертированную подпись?
Опять мимо, для версии 1,15 все проверялось успешно.

Таким образом, данное сообщение об ошибке говорит о том, что запрос,
который Вы отсылаете к сервису имеет некорректную ЭЦП.
-Ну как с этим спорить?

Проверка подписи происходит следующим образом:
- в СМЭВ поступает запрос;
- канонизируется элемент SignedInfo с помощью алгоритма c14n;
- далее расшифровывается SignatureValue с помощью открытого ключа сертификата - x1;
- берется SignedInfo и считается от него хэш - x2,
если x1 не равен x2, СМЭВ возвращает ошибку <Неверная ЭП сообщения.
Если же х1 = х2, то проверка переходит на следующий шаг;
- считается хэш от body запроса - y1 по методу
указанному в DigestMethod. Из DigestValue
получаем - y2. Если y1 не равен y2, то СМЭВ
возвращает ошибку "Неверная ЭП сообщения"

Тут я начал кое что понимать, но кипит наш разум возмущенный.
С какого бодуна SignatureValue содержит подпись всего <SignedInfo>
Всегда считал что это подпись элеменета <ds:DigestValue>

Ситаем сигнатуру классом public class SmevSignedXml : SignedXml
или классом public class SignedXmlPrefix : SignedXml
получаем :


В классе SignedXmlPrefix я не до конца уверен т.к.
Код:
public XmlElement GetXml(string prefix)
{ XmlElement e = this.GetXml(); SetPrefix(prefix, e); return e;}

т.е. все правится добавлением префикса после расчета сингатуры...

И тут начинася самое интересное
Смотрим "Методические рекомендации по разработке веб-сервисов v2.5.6.pdf"
видим слова про TimeStamp и XAdES
в пункте 4,2,2 не видим никаких префиксов для <Signature>
но в примере к этому пункту все с префиксом.
Далее смотрим пункт 5.2.1. видим:
"Так как электронная подпись узла СМЭВ/РСМЭВ содержит метку времени, для её
хранения в электронном сообщении используется расширение стандарта XMLDSIG - XAdES-T."
Все приплыли, смотрим пример и пухнем дальше:

Код:
 <ds:Object>
 <xds:QualifyingProperties xmlns:xds="http://uri.etsi.org/01903/v1.1.1#">
 ...
 <xds:HashDataInfo uri="#signature-value-40ddb6ca-9ac1-4026-a049-76901f3aa5d8"/>
 <xds:EncapsulatedTimeStamp>Метка времени в Base64</xds:EncapsulatedTimeStamp>

видим у xds:HashDataInfo ссылку на то для чего берется TimeStamp
т.е. значение сигнатуры но в примере у элемента <ds:SignatureValue>
нет атрибута Id=signature-value-40ddb6ca-9ac1-4026-a049-76901f3aa5d8
Бардак однако.
И соответственно я поступил по простому, добавил к <ds:SignatureValue>
атрибут Id и соответственно в xds:HashDataInfo ссылку на него.
Вроде ничего криминального <ds:SignedInfo> я не трогаю.
Однако все равно получаю SMEV-100003

Я конечно не Чернышевский, но ЧТО ДЕЛАТЬ? d'oh!
Все вручную? Повторить то, что сделала КриптоПро в КриптоПро.NET?

PS Маленькая шпилька для автора SignedXmlPrefix

Offline Boris@Serezhkin.com  
#42 Оставлено : 27 мая 2015 г. 11:37:04(UTC)
Boris@Serezhkin.com

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

Группы: Участники
Зарегистрирован: 26.08.2010(UTC)
Сообщений: 259
Откуда: Moscow

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Может я не все понимаю?d'oh!
Автор: strelok671 Перейти к цитате

С нового года Казначейство будет требовать подпись собственного запроса в формате XAdES-T. При этом подпись пакета СМЭВ остается старой.

Как подпись пакета СМЭВ может старой ?
А как же "Методические рекомендации по разработке веб-сервисов v2.5.6"
Offline ledonos  
#43 Оставлено : 29 мая 2015 г. 15:15:06(UTC)
ledonos

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

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

Поблагодарили: 1 раз в 1 постах
Автор: Boris@Serezhkin.com Перейти к цитате
Может я не все понимаю?d'oh!
Автор: strelok671 Перейти к цитате

С нового года Казначейство будет требовать подпись собственного запроса в формате XAdES-T. При этом подпись пакета СМЭВ остается старой.

Как подпись пакета СМЭВ может старой ?
А как же "Методические рекомендации по разработке веб-сервисов v2.5.6"


Прочёл Ваше сообщение и решил ещё раз заглянуть в эти рекомендации 2.5.6. А там в разделе 5.4 "Правила формирования электронной подписи информационной систем" всё про XMLDSig, кроме последних двух абзацев, в которых сказано, что при "подписании XML структур данных" рекомендуется использовать стандарт XAdES-T.
А в документации по форматам ГИС ГМП версии 1.16.1 сказано, что везде XAdES-T используется.

Задал вопрос техподдержке ГИС ГМП. Оказалось, что "Под всем запросом по-прежнему стоит XMLDSig, а под импортируемыми в ГИС ГМП сущностями XAdES-T"
thanks 1 пользователь поблагодарил ledonos за этот пост.
Boris@Serezhkin.com оставлено 29.05.2015(UTC)
Offline kkklll  
#44 Оставлено : 2 июня 2015 г. 19:35:15(UTC)
kkklll

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 2 раз в 2 постах
сам soap пакет подписывается как и раньше - ничего не поменялось, пример подписания где-то здесь на КриптоПро есть.
что касается импортируемой сущности, то только она подписывается по XAdES-T. для этой подписи нужен проект с первой страницы, с доработками со второй страницы этой темы.
Offline Boris@Serezhkin.com  
#45 Оставлено : 5 июня 2015 г. 13:31:15(UTC)
Boris@Serezhkin.com

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

Группы: Участники
Зарегистрирован: 26.08.2010(UTC)
Сообщений: 259
Откуда: Moscow

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Добрый день всем.

Хорошо подпись SOAP пакета остается "по старому"
тогда я перестаю окончательно что-либо понимать.
Для 1.15 подпись прекрасно проходит, а если точно так же
подписать для 1.16 получаем
The remote server returned an error: (500) Internal Server Error
и в ответе сервера видим
<faultstring>SMEV-100003: При обработке запроса произошла ошибка: Неверная ЭП сообщения</faultstring>
Think А если запрос 1.15 послать на адрес 1.16

Вопрос если сервер возвращает 500 можно ли верить тому что он возвращает как ответ?

Req116.xml (26kb) загружен 14 раз(а). Req115.xml (12kb) загружен 7 раз(а).

Offline kkklll  
#46 Оставлено : 5 июня 2015 г. 14:11:06(UTC)
kkklll

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 2 раз в 2 постах
ваша ЭП не проходит проверку. ни 116, ни 115
https://smev.gosuslugi.r...ortal/services-tools.jsp
Offline Boris@Serezhkin.com  
#47 Оставлено : 5 июня 2015 г. 16:54:34(UTC)
Boris@Serezhkin.com

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

Группы: Участники
Зарегистрирован: 26.08.2010(UTC)
Сообщений: 259
Откуда: Moscow

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Автор: kkklll Перейти к цитате
ваша ЭП не проходит проверку. ни 116, ни 115
https://smev.gosuslugi.r...ortal/services-tools.jsp


Ну да, сервис проверки для Req115.xml ругается на:
Сообщение не прошло ФЛК [Валидация по МР 2.3.4]. Найдены ошибки: Неверное количество вхождения элемента [/soap:Envelope/soap:Body/*[1]/smev:Message], требуется минимум [1] Неверное количество вхождения элемента [/soap:Envelope/soap:Body/*[1]/smev:MessageData], требуется минимум [1]
- не понятно.

Тестовый сервис ГИСГМП 1.15
http://smev-mvf.test.gosuslugi.ru:7777/gateway/services/SID0003218
прекрасно понимает Req115.xml и дает корректный ответ:
<ErrorCode>8</ErrorCode>
<ErrorDescription>Нет прав на импорт/уточнение сущности данного типа</ErrorDescription>

А вот что не так с Req116.xml - не понимаю.

Кстати, растолкуйте мне пожалуйста
если сервер возвращает 500 можно ли верить тому что он возвращает как ответ?
В каких случаях получаем 500?
С моей точки зрения ежели Internal Server Error, то все остальное от лукавого...Think
Offline Bpar  
#48 Оставлено : 8 июля 2015 г. 10:43:43(UTC)
Bpar

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

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

Поблагодарили: 2 раз в 2 постах
Автор: maxdm Перейти к цитате

Постараемся с ближайшее время сделать пример для .NET.


Может у кого есть работающий пример, который не надо собирать по ссылкам и сообщениям из этой темы? Спасибо.
Offline alex33  
#49 Оставлено : 17 июля 2015 г. 18:39:27(UTC)
alex33

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

Группы: Участники
Зарегистрирован: 15.10.2012(UTC)
Сообщений: 11
Откуда: msc

Сказал(а) «Спасибо»: 1 раз
Пытаюсь осилить XadesT для ГИС ГМП.
Пока результат стабильно отрицательный: ЭП под сущностью неверна

Делал вроде все как в этой теме:
1. Скачал исходники Microsoft.Xades
2. Заменил AddXadesObject вариантом от strelok671
3. Подписываю по аналогии из TestClient

дальше непонятки...

1. httpTsaClient.ComputeHashValueOfElementList - там хеш считается по SHA1. Это правильно? Кажется логичнее по ГОСТу считать.
Пересчитывал по госту, но там длина хеша != 20 байт, и банан случается на SendTsaWebRequest - там жесткая проверка на длину хеша.
Надо править BuildTsaRequest ? или это не правильный путь?

Вообщем подскажите куда копать)

UPD: Попробовал вариант BuildTsaRequest от Blaksa и хеш руками посчитаный по ГОСТу. Вроде отправляет, но подписать все равно не верна.
Есть какие-то хитрости при формировании SignedProperties и UnsignedProperties ?

Отредактировано пользователем 17 июля 2015 г. 18:56:50(UTC)  | Причина: Не указана

Offline strelok671  
#50 Оставлено : 21 июля 2015 г. 12:20:01(UTC)
strelok671

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 2 раз в 2 постах
Автор: alex33 Перейти к цитате
Пытаюсь осилить XadesT для ГИС ГМП.
Пока результат стабильно отрицательный: ЭП под сущностью неверна

Делал вроде все как в этой теме:
1. Скачал исходники Microsoft.Xades
2. Заменил AddXadesObject вариантом от strelok671
3. Подписываю по аналогии из TestClient

дальше непонятки...

1. httpTsaClient.ComputeHashValueOfElementList - там хеш считается по SHA1. Это правильно? Кажется логичнее по ГОСТу считать.
Пересчитывал по госту, но там длина хеша != 20 байт, и банан случается на SendTsaWebRequest - там жесткая проверка на длину хеша.
Надо править BuildTsaRequest ? или это не правильный путь?

Вообщем подскажите куда копать)

UPD: Попробовал вариант BuildTsaRequest от Blaksa и хеш руками посчитаный по ГОСТу. Вроде отправляет, но подписать все равно не верна.
Есть какие-то хитрости при формировании SignedProperties и UnsignedProperties ?


Самое смешное, что Казначейство не в состоянии предоставить список сертифицированных TSA серверов с алгоритмами ГОСТ для боевого канала. Поэтому для боевого канала метки времени пришлось выкусывать. Так что сильно не напрягайтесь :)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
9 Страницы«<34567>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.