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

Уведомление

Icon
Error
2 Страницы12>
Не могу проверить одну из двух подписей (СМЭВ) - Не могу проверить одну из двух подписей (СМЭВ)
Опции
К последнему сообщению К первому непрочитанному
Предыдущая тема Следующая тема
Offline alex33  
#1 Оставлено : 19 июля 2013 г. 11:51:44(UTC)
alex33

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

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

Сказал(а) «Спасибо»: 1 раз
1. КриптоПро CSP 3.6.7491
2. КриптоПро .NET Клиент 1.0.4812.0

Мой клиент (.NET FW 4) получает из СМЭВ ответ на запрос, и не может проверить подпись СМЭВ. При этом подпись ОВ проверяется нормально.
Пробовал два варианта:
1. Проверка ручками, так как в статье http://www.cryptopro.ru/...lzovaniem-kriptopro-net.

signedXml.CheckSignature(cert.PublicKey.Key) возвращает false. А именно метода SignedXml.CheckSignedInfo(AsymmetricAlgorithm key) в последней строке return asymmetricSignatureDeformatter.VerifySignature(hashval, m_signature.SignatureValue);


2. С использованием SMEVMessageEncodingBindingElement (на основании примера из SDK)

Тут вообще интересная ошибка: "The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected."

Пример ответа, который успешно валидирует все подписи на http://smev.gosuslugi.ru/portal/services-tools.jsp в присоединении.

Куда копать? Чего делать?
Вложение(я):
response2.xml (8kb) загружен 15 раз(а).

У Вас нет прав для просмотра или загрузки вложений. Попробуйте зарегистрироваться.
Вверх

Wanna join the discussion?! Login to your Форум КриптоПро forum account, or Register a new forum account.
Вверх  
Offline evgenyga  
#2 Оставлено : 8 июля 2014 г. 9:53:54(UTC)
evgenyga

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

Группы: Участники
Зарегистрирован: 07.07.2014(UTC)
Сообщений: 2
Российская Федерация
Откуда: Москва
alex33 добрый день! У меня тоже такая проблема! Скажите, Вы резобрались как избавиться от этой ошибки?
Вверх
Offline Bpar  
#3 Оставлено : 5 августа 2014 г. 10:48:59(UTC)
Bpar

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

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

Поблагодарили: 2 раз в 2 постах
Поддерживаю предыдущих авторов.
Где-то до 16 июля всё работало нормально на продуктивной среде. WCF всё проглатывало и верифицировало без ошибок.
17.07.2014 стала выдаватьсошибка "Алгоритм ключа сертификата не поддерживается."
А сейчас "Входящее сообщение было подписано маркером, отличающимся от маркера, использованного для шифрования тела сообщения. Ожидалось, что маркеры будут одинаковы.", что в переводе на английский и есть та, которую обозначил Alex33.
Вот здесь написано:
"If we use ProtectionLevel.Sign, meaning we only sign messages but do not encrypt them, then the service certificate which we configure on the client is only used for the purpose of validating the response signature. So we are free to change it to be the actual signing certificate. In some cases we may not know what this certificate is. Apart from asking the service author to provide it we can examine the response (as above) and extract the certificate from the binary security token (which may not always exist though)."

На сколько я понял, предлагается узнать сертификат сервера и подсовывать его в
/// Серверный сертификат подписи
service.ClientCredentials.ServiceCertificate.DefaultCertificate = serverCert;
Раньше я туда подсовывал сертификат УЦ.
=================
В-общем берём Fiddler, нюхаем ответы сервера, находим там первый binarySecurityToken, Там-же конвертим его из Base64 и сохраняем в файл .CER. Импортируем этот сертификат и подсовываем его в DefaultCertificate.

Отредактировано пользователем 5 августа 2014 г. 13:56:58(UTC)  | Причина: Пробленма решена
Вверх
thanks 1 пользователь поблагодарил Bpar за этот пост.
ESofter оставлено 22.01.2015(UTC)
Offline Boris@Serezhkin.com  
#4 Оставлено : 27 июля 2015 г. 0:10:51(UTC)
Boris@Serezhkin.com

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Think Случайно попалась на глаза эта тема.
Решил проверить что же мне СМЭВ совместно с ГИСГМП шлет.
За основу взял проверку подписи из примера SignSmevRequest.cs
получил следующее:
Код:
Отправляем файл D:\ovi\Smev_bx\bin\Debug\r_pm4.Xml
Пишем ответ на диск: D:\ovi\Smev_bx\bin\Debug\t_pm4.Xml
проверка подписей: Найдено 2.
НЕ верна. Узел = smev:Header URI=#ID-302bdb92-19de-417d-827e-c19eb29e2e25
  Сертификат = Сертификат ЭП-СМЭВ\Тестовый УЦ РТК (РТЛабс)
== верна. Узел = S:Body URI=#body
  Сертификат = Федеральное казначейство\УЦ Федерального казначейства
ResultCode=0
ResultData=ID_fffbf362-b709-4d02-8ec9-a56fafcb9355

Я не знаю кто такая WCF, год назад попробовал, тяжело и неудобно.
Все ведь просто. Сделали из xml файла поток, отправили, приняли поток
ответа. Сохранили как xml. проверили и получили.
Если посмотреть на ответ СМЭВ, то видно что есть два узла wsse:Security
Для одного S:actor=".../recipient", а для другого S:actor=".../smev".
На что это влияет я не знаю, не разбирался.
Вторая подпись прекрасно проверяется стандартным signedXml
А вот если посмотреть на первую, то видно, что есть два элемента ds:Reference
ds:Reference URI="#ID-dab2a1bd-548a-417b-b8b2-731a3efa4fde"
- ссылка на smev:Header лежащий внутри S:Header
и ds:Reference URI="#body" - ссылка на S:Body
Сертификаты подписей присутствуют.

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

Ранее я не думал об одновременной подписи нескольких узлов. нет необходимости.
Скорее всего при подписи надо:
signedXml.AddReference(reference1);
signedXml.AddReference(reference2);
signedXml.AddReference(reference3);
...

А вот как проверить идей нет. Так как СМЭВ фунциклирует, то проблема решаемая.
Но интересует решение на шарпе.

Кто нибудь решал эту проблему?

Прилагаю ответ СМЭВ-а t_pm4.Xml (13kb) загружен 3 раз(а).
Вверх
Offline Boris@Serezhkin.com  
#5 Оставлено : 27 июля 2015 г. 1:25:00(UTC)
Boris@Serezhkin.com

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Вот не было у бабы заботы, купила баба порося...Drool

Ситуация следующая - мне дают xml состоящий из <smev:MessageData>...
Я на него смотрю и ежели вижу пустой узел Signature, то подписываю
вышележащий узел. Вставляю полученное в СМЭВ пакет и подписываю его.

Посмотрев на проверку ответа СМЭВ я решил проверить и то что я ему отдаю.
Цитата:
Все чудесатее и чудесатее сказала Алиса.

Если входной пакет не требует подписи (запрос статуса), то проверить ВСЕ подписи
отвечает - есть одна, правильная.
Если есть одна подпись во входном файле то проверка говорит есть одна и правильная,
но после обертки в СМЭВ пакет говорит есть две подписи, обе не верны
Код:
Тип файла: CHARGE  Id=CE61F6BA-A378-404E-84F9-4DF80CF03AED
Charge Id=A_4BC77441-3BDD-467A-92AD-F1EF722F98DA
проверка подписей: Найдено 1.
== верна. Узел = chg:Charge URI=#A_4BC77441-3BDD-467A-92AD-F1EF722F98DA
Подготавливаем запрос. Подписываем запрос.
проверка подписей: Найдено 2.
НЕ верна. Узел = S:Body URI=#body
НЕ верна. Узел = chg:Charge URI=#A_4BC77441-3BDD-467A-92AD-F1EF722F98DA
Отправляем файл D:\ovi\Smev_bx\bin\Debug\r_ch0.Xml

Только все это обман. СМЭВ считает что все хорошо.

Согласно формату ГИСГМП 1,16 в одном пакете можно передавать несколько начислений.
Наши так и сделали. Я пробежался, подписал все требуемые узлы.
Проверка подписанного входного файла сообщила интересный результат:
Код:
проверка подписей: Найдено 4.
== верна. Узел = pi:FinalPayment URI=#A_912F4341-BB89-46C4-BDFF-91A0922962C2
НЕ верна. Узел = pi:FinalPayment URI=#A_AF766A08-E75C-4CE0-998A-151BFE854628
НЕ верна. Узел = pi:FinalPayment URI=#A_644BFECA-F4E9-4326-BA12-0A638ECF067E
НЕ верна. Узел = pi:FinalPayment URI=#A_62F3747E-72DF-416E-A956-9DE39F24CF8B

Если бы все подписи не проверились, я бы не удивился, а так Think
Но все равно СМЭВ считает что все хорошо.

Проверка все та же: Для каждого узла Signature загружаем его в signedXml
и проверяем .

У меня руки кривые ? Или у мелкософта?
Наверное если каждый узел signedXml вместе с подписываемым узлом вынести в новый
xmlDocument, то он проверится. Но это не красиво.

Как быть?

Может кто захочет проверить подписи ? inxml.xml (26kb) загружен 3 раз(а).
Вверх
Offline Boris@Serezhkin.com  
#6 Оставлено : 28 июля 2015 г. 11:40:07(UTC)
Boris@Serezhkin.com

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Dancing Опять про подпись с несколькими ссылками:
Автор: Boris@Serezhkin.com Перейти к цитате
Скорее всего при подписи надо:
signedXml.AddReference(reference1);
signedXml.AddReference(reference2);
signedXml.AddReference(reference3);
...


Вот сотворил пример одновременно подписываются
два узла из трех и проверяется подпись.
Подпись верна.
Пример простой без префиксов и т.д. А`ля Криптопро. Boo hoo!

to CryptoPro: Может имеет смысл внести в комплект примеров?

А вот для ответа СМЭВ надо разобраться с префиксами и именами...Brick wall

Sign2Node.cs.txt (9kb) загружен 12 раз(а).
Вверх
Offline Boris@Serezhkin.com  
#7 Оставлено : 28 июля 2015 г. 14:43:28(UTC)
Boris@Serezhkin.com

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

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

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

Результат не удивляет, но ПОЧЕМУ ???
Код:
Пример 8: N узлов, подписывается каждый
          и доплнительно подписываются N узлов вместе

Создан XML файл: doc_to_sign.xml
XML подписан   : doc_signed.xml

Найдено подписей 5
Подпись 1 true  URI = "#Id_1"
Подпись 2 false URI = "#Id_2"
Подпись 3 false URI = "#Id_4"
Подпись 4 false URI = "#Id_5"
Подпись 5 true  URI = "#Id_1"+"#Id_2"+"#Id_4"+"#Id_5"

press any key...

SignEveryNode.cs.txt (10kb) загружен 9 раз(а).

А вот если в примере убрать комментарий со строки 137,
т.е. добавить итоговую подпись в начало документа,
то полные непонятки.
все 6 подписей неверны.

Повторюсь ПОЧЕМУ ???
Вверх
Offline Boris@Serezhkin.com  
#8 Оставлено : 28 июля 2015 г. 19:32:04(UTC)
Boris@Serezhkin.com

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Возникла мысль, а если все дело в том, что все узлы называются одинаково?d'oh!
Я её подумал, проверил...
Даже если узлы называются Node1,Node2,Node3,Node4,Node5
результат тот же... УВЫ.Boo hoo!

Отредактировано пользователем 28 июля 2015 г. 19:32:43(UTC)  | Причина: Не указана
Вверх
Offline khomenko  
#9 Оставлено : 31 июля 2015 г. 14:39:30(UTC)
Михаил Хоменко

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

Группы: Администраторы, Участники
Зарегистрирован: 28.04.2010(UTC)
Сообщений: 140
Мужчина
Откуда: Крипто-Про

Поблагодарили: 15 раз в 14 постах
Добрый день,

В общих чертах проблема локализована. Есть большое подозрение, что не корректно работает трансформ XmlDsigEnvelopedSignatureTransform.
Трансформ должен исключать узел Signature из проверяемого элемента, но делает он это корректно только для первого узла. Для остальных начинает где-то путаться.

Т.е. сами подписи верны, но они не верно проверяются.

При проверке enveloped подписей, вложенный в узлы ElementToSign, нужно удалить все предыдущие узлы Signature.

Делается примерно так:

Цитата:
XmlNamespaceManager _nsm2 = new XmlNamespaceManager(xmlDocument.NameTable);
_nsm2.AddNamespace("dsig", "http://www.w3.org/2000/09/xmldsig#");
XmlNodeList nlist = xmlDocument.SelectNodes("//dsig:Signature", _nsm2);

for (int j = 0; j < nlist.Count; j++)
{
XmlElement elem = nlist[j] as XmlElement;
SignedXml signedXml = new SignedXml(xmlDocument);
signedXml.LoadXml(elem);
bool ret = signedXml.CheckSignature();

nlist[j].ParentNode.RemoveChild(nlist[j]);
}



Естественно при этом сломается проверка подписи, поставленной подо всеми узлами ElementToSign.
Её придётся проверять отдельно - переоткрывая документ
doc_signed.xml (12kb) загружен 6 раз(а). doc_to_sign.xml (1kb) загружен 4 раз(а).

Отредактировано пользователем 31 июля 2015 г. 14:40:18(UTC)  | Причина: Не указана
Вверх
thanks 1 пользователь поблагодарил Михаил Хоменко за этот пост.
Boris@Serezhkin.com оставлено 01.08.2015(UTC)
Offline Boris@Serezhkin.com  
#10 Оставлено : 3 августа 2015 г. 2:20:04(UTC)
Boris@Serezhkin.com

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 11 раз в 10 постах
Век живи, век учись.Drool
Я смог проверить обе подписи ответа СМЭВ
Цитата:
Сохраняем ответ: D:\ovi\Smev_bx\bin\Debug\pm1.XML
проверка подписей: Найдено 2.
== верна. Body = smev:Header;S:Body URI = "#ID-5eb671a7-0840-4465-a461-8c1786e906e0"+"#body"
Сертификат = Сертификат ЭП-СМЭВ\Тестовый УЦ РТК (РТЛабс)
== верна. Body = S:Body URI = "#body"
Сертификат = Федеральное казначейство\УЦ Федерального казначейства
ResultCode=0
ResultData=ID_123d9183-c190-4681-bafd-8d18558785a2
Формируем запрос статуса для ID_123d9183-c190-4681-bafd-8d18558785a2

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

Кто бы мне разъяснил что подразумевается под "расшифровывается SignatureValue" в методах "Gost3410CryptoServiceProvider".
Как из SignatureValue получить подписанный хэш? Think

Однако вернемся к нашим баранам.
Я привык смотреть и редактировать XML FAR-ом. так что всегда сохраняю ХМЛ на диск форматированным, т.е. xmltw.Formatting = Formatting.Indented;
и загружаю их с диска с .PreserveWhitespace = false;
Не знаю что меня сподвигло, но я сохранил полученный с сервиса поток в файл, без предварительной загрузки в ХМЛ и форматированного сохранения.
Посмотрел на него глазками. первая Signature идет через 0x0A т.е. LF
даже SignatureValue разрезана лайнфидом на две части.
больше в данных ни LF ни CRLF нет.
Думаю что далее всем все понятно. надо сразу по приему загружать данные
в XmlDocument с .PreserveWhitespace = !false;
И все проверится.Boo hoo!
Однако очень ломает ложить в базу неформатированые ХМЛи.
Кроме меня у нас есть еще любители посмотреть глазками.
Т.е. девочки вываливают пользователям ХМЛ из базы в textboxDancing

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

Privacy Policy | Форум YAF.NET | YAF.NET © 2003-2024, Yet Another Forum.NET