Статус: Участник
Группы: Участники
Зарегистрирован: 04.08.2019(UTC) Сообщений: 19  Сказал(а) «Спасибо»: 4 раз
|
Цитата:Конечно, это может быть причиной, однако в данном случае namespace добавлены верно, Да ,я уже понял что ошибался по этому поводу. Цитата:тег DigestMethod без префикса и namespace, судя потому что каноническая форма Да - это уже был результат моих экспериментов - не заметил что выложил -в там есть Код:System.Security.Cryptography.Xml.SignedXml Verbose: 8 : [Reference#00245fb7, ReferenceData] Преобразованный контент ссылки: <xades:SignedProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Id="xmldsig-ccfc94ce-37e9-472b-be0d-9301c0937235-signedprops"><xades:SignedSignatureProperties><xades:SigningTime>2019-09-10T10:02:38.126+03:00</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></ds:DigestMethod><ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">iHgldkUfYZurm1/OAbbFFDqWcoxxHgtmUcbVBEWVKlU=</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">1.2.840.113549.1.9.1=ca_tensor@tensor.ru,1.2.643.100.1=1027600787994,1.2.643.3.131.1.1=007605016030,C=RU,ST=76 Ярославская область,L=г. Ярославль,STREET=Московский проспект д.12,OU=Удостоверяющий центр,O=ООО \"КОМПАНИЯ \"ТЕНЗОР\",CN=ООО \"КОМПАНИЯ \"ТЕНЗОР\"</ds:X509IssuerName><ds:X509SerialNumber xmlns:ds="http://www.w3.org/2000/09/xmldsig#">51038696132506063092011207922305402410</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties></xades:SignedProperties>
Что- то делаю не так... простой код для примера Цитата: XmlDsigExcC14NTransform t = new XmlDsigExcC14NTransform();
XmlNodeList Dls = XM.GetElementsByTagName("xades:SignedProperties");
XmlNode node = Dls[0];
XmlDocument xmnew = new XmlDocument();
xmnew.LoadXml(node.OuterXml);
t.LoadInput(xmnew);
MemoryStream s = (MemoryStream)t.GetOutput(typeof(MemoryStream));
var hash = HashAlgorithm.Create("GOST3411_2012_256");
var hashvalue = Convert.ToBase64String(hash.ComputeHash(s));
Т.е. выбираю xades:SignedProperties, делаю XmlDsigExcC14NTransform, получаю хэш в base64 где XM подписанный документ - получаю hashvalue аналогичное тому что записано в DigestValue в после моего подписания Для референса 1 то же самое сходится Если то же самое делаю с примером от ГИС ЖКХ (то что подписано тестовым сертификатом), то естесновенно значения не сходятся) Цитата:в итоговом документе присутствую отступы пробелами перед тегами и переводы строк, а на отладке расчета DigestValue они отсутствуют (опять PreserveWhitespace... что-то мне кажется без точного понимания откуда что идет его изменение сделает
только хуже, так как в коде тьма методов GetXml и надо похоже найти все и явно указать PreserveWhitespace); Да куча методов GetXml....то что правил PreserveWhitespace лучше не стало В любом случае спасибо за комментарии...очень помогают...пошел разбираться
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: oleg_kashin  Для референса 1 то же самое сходится К первому референсу надо применять еще и enveloped-signature transform, поэтому либо берете подписываемый тег для первого трансформа из неподписанного документа (что эквивалентно выполнению enveloped-signature transform) либо должно выдавать ошибку. А для второго не сходится? Автор: oleg_kashin Если то же самое делаю с примером от ГИС ЖКХ (то что подписано тестовым сертификатом), то естесновенно значения не сходятся) Если только по такому фрагменту кода, то без разницы чем подписано, подпись тут не проверяется и сертификат не участвует, в примере также использется эксклюзивная каноническая форма, то есть должно сходится если все делается правильно.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 04.08.2019(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 4 раз
|
Да, саму подпись я не проверяю- только значения DigestValue Если я не могу проверить DigestValue по примеру ГИС ЖКХ, который точно верный (кстати http://dss.cryptopro.ru/Verify/Verify/ он тоже проходит), при том что сходятся DigestValue в подписанном мною - то явно у меня что-то не так)) Подписанный мною xml - пример вот  out.xml (9kb) загружен 3 раз(а).Для первого референс  Собственно которое совпадает со значением в out.xml Цитата:К первому референсу надо применять еще и enveloped-signature transform, поэтому либо берете подписываемый тег для первого трансформа из неподписанного документа Эм..беру тег из подписанного документа out.xml и удаляю child ds:Signature По логике должен сначала выполнить XmlDsigEnvelopedSignatureTransform (ее как XmlDsigExcC14NTransform как понял так просто не выполнишь), потом XmlDsigExcC14NTransform но делал только XmlDsigExcC14NTransform 2 реферанс  Тоже совпадает со значением в out.xml С примером от ГИС ЖКХ ничего не совпадает соответвенно Отредактировано пользователем 10 сентября 2019 г. 12:15:02(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: oleg_kashin Если я не могу проверить DigestValue по примеру ГИС ЖКХ, который точно верный, при том что сходятся DigestValue в подписанном мною - то явно у меня что-то не так)) Логично. Автор: oleg_kashin для первого референса... Собственно которое совпадает со значением в out.xml Цитата:К первому референсу надо применять еще и enveloped-signature transform, поэтому либо берете подписываемый тег для первого трансформа из неподписанного документа Эм..беру тег из подписанного документа out.xml и удаляю child ds:Signature По логике должен сначала выполнить XmlDsigEnvelopedSignatureTransform (ее как XmlDsigExcC14NTransform как понял так просто не выполнишь), потом XmlDsigExcC14NTransform но делал только XmlDsigExcC14NTransform В принципе удаление тоже подойдет, однако есть НО. Меня смущает вот что: перед Signature идет перевод строки и отступ и после Signature идет перевод строки. В норме добавление Signature не должно добавлять перевода строки и отступа (даже если они есть в других местах), то есть перевод строки должен быть только в одном месте или до или после. Трансформ XmlDsigEnvelopedSignatureTransform также не трогает отступы и переводы строки. Если при удалении child ds:Signature также исчезает перевод строки и отступ, то это отличается от применения трансформа XmlDsigEnvelopedSignatureTransform. Без отступов и переводов строки отличия бы не было в принципе. Кроме того, страннно что в обычном блокноте переводы строки показывает правильно - это означает что переводы строк в файле в формате Windows - символ 13+символ 10. В норме из Xml объекта должны выходить только символы 10 как переводы строки без символов 13 вообще. Автор: oleg_kashin 2 реферанс... Тоже совпадает со значением в out.xml С примером от ГИС ЖКХ ничего не совпадает соответвенно А есть отдельно значения после трансформов, от которых хэш посчитан? К слову, когда я первый раз все отлаживал, то фиксировал guid и время, чтобы хэш всегда был одинаковый на время отладки. По свежему out.xml выходит вот что:
SignedInfo как есть (без удаления пробелов):
HASH OID = 1.2.643.7.1.1.2.2
0D37 7EA1 764C BB67 DF84 3B78 2FB5 5FF9 6BE6 5E44 4FFD A18C 7D07 C0CA FAC4 CBA6
[DTd+oXZMu2ffhDt4L7Vf+WvmXkRP/aGMfQfAyvrEy6Y=]
=== INFO: Signature fail
========== DO CHECK WITHOUT LF ==========
SignedInfo с удалением символов с кодом 10 (без удаления пробелов):
HASH OID = 1.2.643.7.1.1.2.2
9AB7 9E42 A89D 6DDB 83B4 3EEA D5B1 8011 2391 4A40 83C1 A3AC B750 43D8 D50F 5446
[mreeQqidbduDtD7q1bGAESORSkCDwaOst1BD2NUPVEY=]
=== WARNING: Signature fail
референс 1:
HASH OID = 1.2.643.7.1.1.2.2
66DE AAF3 DAB5 39F8 5C2E 672A 1F0B 63D4 3F32 8ACE 5512 1EC1 4DE9 C81B 79FE 2A29
[Zt6q89q1OfhcLmcqHwtj1D8yis5VEh7BTenIG3n+Kik=]
=== WARNING: digest differ:
[9G3SK46aX/tJYGse7V5KzJLxbjp7OLS7Edi/3/zQVCw=] expected
[Zt6q89q1OfhcLmcqHwtj1D8yis5VEh7BTenIG3n+Kik=] fact
референс 2:
HASH OID = 1.2.643.7.1.1.2.2
8D08 B92A 6C41 3525 056A 0F35 1A85 1E44 CC53 D824 7389 541E DF66 5EB4 186B F800
[jQi5KmxBNSUFag81GoUeRMxT2CRziVQe32ZetBhr+AA=]
=== WARNING: digest differ:
[Op3TPPQSZNPB3UzDQTwckDGe1S2ieEbGlVOEtHwiPO8=] expected
[jQi5KmxBNSUFag81GoUeRMxT2CRziVQe32ZetBhr+AA=] fact
Из-за пробелов конечно не претендую на правильность хэша, в "пример 2012" были табуляции, сошлось без удаления табуляций и символов 10. Перечитал статью по каноникализации - там объясняют как нормализовать whitespace в тегах и простых атрибутах, по сложным атрибутам отправляют к стандарту, по текстовым узлам между тегами вообще не говорят, тоже в стандарты надо лезть. Отредактировано пользователем 11 сентября 2019 г. 7:35:46(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 04.08.2019(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 4 раз
|
Цитата:А есть отдельно значения после трансформов, от которых хэш посчитан? Есть - вот пример по "Пример 2012" для расчета 1 референса До трансформа Цитата:<exportNsiListRequest xmlns="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/nsi/" Id="foo"><!--Элемент, описывающий бизнес-данные--></exportNsiListRequest> После трансформа Цитата:<exportNsiListRequest xmlns="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/nsi/" Id="foo"></exportNsiListRequest> Значение DigestValue Sy4p9nNDo98EhitWdc2HOlDMEF/OgVi2WAzWZDzRjUY= не сходится с данными в примере RML7HeI83whzrRjK3S02X4MlVGrSIIWHVC3x3la+IZc= То же самое с { PreserveWhitespace = true }До трансформа Цитата:<exportNsiListRequest xmlns="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/nsi/" Id="foo">
<!--Элемент, описывающий бизнес-данные-->
</exportNsiListRequest> После трансформа Цитата:<exportNsiListRequest xmlns="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/nsi/" Id="foo">
</exportNsiListRequest> Значение хэша в этом случае MXMWK37PKVieUkHdD12cd3FixLKVeVz8zdWPO85DbN0= тоже не сходится Можете дать что идет на счет DigestValue 1 референса в Вашей программе по примеру "Пример 2012" и последний out.xml? - будут очень благодарен В моем примере по out.xml получается одинаково до и после трансформа - нет комментариев Цитата:<hous:exportHouseRequest xmlns:base="http://dom.gosuslugi.ru/schema/integration/base/" xmlns:hous="http://dom.gosuslugi.ru/schema/integration/house-management/" Id="a06356a7e8bd4239ad69b3e9c949bca1" base:version="11.1.0.1"><hous:FIASHouseGuid>23159e35-673f-4b45-952f-b80bbd5f4110</hous:FIASHouseGuid></hous:exportHouseRequest> Цитата:К слову, когда я первый раз все отлаживал, то фиксировал guid и время, чтобы хэш всегда был одинаковый на время отладки Всмысле тэг <xades:SigningTime> и id. По первому референсу давно не менял Id="a06356a7e8bd4239ad69b3e9c949bca1" - там стабильно должен идти один и тот же DigestValue Отредактировано пользователем 11 сентября 2019 г. 11:39:49(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: oleg_kashin Цитата:А есть отдельно значения после трансформов, от которых хэш посчитан? Есть - вот пример по "Пример 2012" для расчета 1 референса ... То же самое с { PreserveWhitespace = true }... Можете дать что идет на счет DigestValue 1 референса в Вашей программе по примеру "Пример 2012" и последний out.xml? - будут очень благодарен Конечно могу, программа пишет логи и значения референсов в файлы. c решетками это референсы после трансформа, log1/log2 это лог подсчет хэша этих файлов референсов, signedinfo после трансформа и на всякий случай большой лог проверки. refs.zip (27kb) загружен 6 раз(а).С PreserveWhitespace = true в принципе похоже на выданное программкой. Автор: oleg_kashin В моем примере по out.xml получается одинаково до и после трансформа - нет комментариев Зато есть отступы и переводы строк, так что строки могут отличаться. Автор: oleg_kashin Цитата:К слову, когда я первый раз все отлаживал, то фиксировал guid и время, чтобы хэш всегда был одинаковый на время отладки Всмысле тэг <xades:SigningTime> и id. По первому референсу давно не менял Id="a06356a7e8bd4239ad69b3e9c949bca1" - там стабильно должен идти один и тот же DigestValue Да, время, и есть еще Id подписи от которого выходит xmldsig-...-signedprops.. Отредактировано пользователем 11 сентября 2019 г. 14:35:59(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 04.08.2019(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 4 раз
|
Цитата:НО. Меня смущает вот что: перед Signature идет перевод строки и отступ и после Signature идет перевод строки. В норме добавление Signature не должно добавлять перевода строки и отступа (даже если они есть в других местах), то есть перевод строки должен быть только в одном месте или до или после. Трансформ XmlDsigEnvelopedSignatureTransform также не трогает отступы и переводы строки. Если при удалении child ds:Signature также исчезает перевод строки и отступ, то это отличается от применения трансформа XmlDsigEnvelopedSignatureTransform. Без отступов и переводов строки отличия бы не было в принципе. Да, разница была только в символах \r на месте удаленного Signature. В моем документе out.xml в тэге hous:exportHouseRequest \r не было - DigestValue рассчитывалось вместе с \r - поэтому мои значения не сходились. В своем разбирался с PreserveWhitespace - да, так просто его менять на false нельзя - сходиться ничего не будет. Теперь получаю подписанную out.xml out.xml (8kb) загружен 7 раз(а)., которую http://dss.cryptopro.ru/Verify/Verify/ пишет как подпись корректна, но ГИС ЖКХ опять та же ошибка формата подписи запроса. может действительно как то по другому считать "DigestValue группы тэгов SigningCertificate" как писала поддержка ГИС ЖКХ - ощущение что уже хожу по кругу. Отредактировано пользователем 12 сентября 2019 г. 16:08:56(UTC)
| Причина: чушь написал
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 04.08.2019(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 4 раз
|
Цитата:может действительно как то по другому считать "DigestValue группы тэгов SigningCertificate" как писала поддержка ГИС ЖКХ - ощущение что уже хожу по кругу. стр 36 https://www.etsi.org/del...60/ts_101903v010402p.pdfЦитата:The element CertDigest contains the digest of one of the certificates referenced in the sequence. It contains two
elements: ds:DigestMethod indicates the digest algorithm and ds:DigestValue contains the base-64 encoded
value of the digest computed on the DER-encoded certificate.
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Да, этот вариант из сообщения 27 у меня тоже сходится (сама подпись без переводов строки, наверно будет полезно знать как такого добиться на будущее). Значит гис жкх спотыкается на проверке того, чего у меня не проверяется. На портале возможно определился другой вид подписи (не xades-bes, а базовый xmldsig). Не помню писал ли тут, у меня есть еще подозрения насчет: 1) атрибута Id="xmldsig-2bbd06d0-0f95-4df1-9b65-07a0b3ea3d8c" у ds:KeyInfo, там он не особо нужен (хотя и не мешает судя по примеру); 2) опять же по примеру (да и по стандарту) у ds:Signature должен быть атрибут Id="xmldsig-d7d7964f-8596-4dcb-acd2-19cb2d864d51" (согласованный с xades:QualifyingProperties атрибутом Target="#xmldsig-d7d7964f-8596-4dcb-acd2-19cb2d864d51", но без решетки). Для теста можно просто аккуратно его дописать в готовый out.xml и попробовать отправить (это место не попадает в хэширование). Отредактировано пользователем 16 сентября 2019 г. 6:03:21(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 14.09.2019(UTC)
Сообщений: 2
Поблагодарили: 3 раз в 1 постах
|
Автор: oleg_kashin Помогите разобраться с подписью запросов к сервису ГИС ЖКХ с использованием ключа по ГОСТ2012 Раньше использовался c ключом по ГОСТу2001 код на основе https://github.com/Good-...itan/signature-demo-net.Переделка исходного приложения с заменой алгоритмов хэширования,подписи с XmlDsigGost3410UrlObsolete, XmlDsigGost3411UrlObsolete на XmlDsigGost3410_2012_256Url,XmlDsigGost3411_2012_256Url и заменой на Gost3410_2012_256CryptoServiceProvider дала странный результат Добрый день. Несколько дней я мучался с той же проблемой, что и oleg_kashin. Я сам использую модифицированую версию xades-demo и после получения электронного ключа с подписью по ГОСТ 2012 получил ошибку. После переделывания xades-demo уперся в ту же ошибку "AUT011005 Ошибка формата подписи запроса". У меня в знаний в криптографии всего ничего, просто старался сделать запрос максимально похожим на ответ от ГИС ЖКХ. После чтения этой темы попробовал убрать переводы строк и форматирование из XML и мне повезло - сейчас мои запросы корректно обрабатываются ГИС ЖКХ. Прикладываю исходники, возможно вам пригодятся. Я внес некоторые изменения в порядок работы утилиты, используются дополнительные аргументы при вызове. Но подписание запросов осталось по той же схеме. gis-zkh-exch.zip (851kb) загружен 40 раз(а).
|
 3 пользователей поблагодарили Юрий Пичугин за этот пост.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
