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

Уведомление

Icon
Error

4 Страницы<1234>
Опции
К последнему сообщению К первому непрочитанному
Offline oleg_kashin  
#21 Оставлено : 10 сентября 2019 г. 10:18:09(UTC)
oleg_kashin

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

Группы: Участники
Зарегистрирован: 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 лучше не стало
В любом случае спасибо за комментарии...очень помогают...пошел разбираться
Offline two_oceans  
#22 Оставлено : 10 сентября 2019 г. 10:36:44(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: oleg_kashin Перейти к цитате
Для референса 1 то же самое сходится
К первому референсу надо применять еще и enveloped-signature transform, поэтому либо берете подписываемый тег для первого трансформа из неподписанного документа (что эквивалентно выполнению enveloped-signature transform) либо должно выдавать ошибку. А для второго не сходится?
Автор: oleg_kashin Перейти к цитате
Если то же самое делаю с примером от ГИС ЖКХ (то что подписано тестовым сертификатом), то естесновенно значения не сходятся)
Если только по такому фрагменту кода, то без разницы чем подписано, подпись тут не проверяется и сертификат не участвует, в примере также использется эксклюзивная каноническая форма, то есть должно сходится если все делается правильно.

Offline oleg_kashin  
#23 Оставлено : 10 сентября 2019 г. 12:11:16(UTC)
oleg_kashin

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

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

Сказал(а) «Спасибо»: 4 раз
Да, саму подпись я не проверяю- только значения DigestValue
Если я не могу проверить DigestValue по примеру ГИС ЖКХ, который точно верный (кстати http://dss.cryptopro.ru/Verify/Verify/ он тоже проходит), при том что сходятся DigestValue в подписанном мною - то явно у меня что-то не так))
Подписанный мною xml - пример вот
out.xml (9kb) загружен 3 раз(а).
Для первого референс
UserPostedImage
Собственно которое совпадает со значением в out.xml
Цитата:
К первому референсу надо применять еще и enveloped-signature transform, поэтому либо берете подписываемый тег для первого трансформа из неподписанного документа

Эм..беру тег из подписанного документа out.xml и удаляю child ds:Signature
По логике должен сначала выполнить XmlDsigEnvelopedSignatureTransform (ее как XmlDsigExcC14NTransform как понял так просто не выполнишь), потом XmlDsigExcC14NTransform но делал только XmlDsigExcC14NTransform
2 реферанс
UserPostedImage
Тоже совпадает со значением в out.xml

С примером от ГИС ЖКХ ничего не совпадает соответвенно

Отредактировано пользователем 10 сентября 2019 г. 12:15:02(UTC)  | Причина: Не указана

Offline two_oceans  
#24 Оставлено : 11 сентября 2019 г. 7:26:36(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 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 выходит вот что:
Из-за пробелов конечно не претендую на правильность хэша, в "пример 2012" были табуляции, сошлось без удаления табуляций и символов 10. Перечитал статью по каноникализации - там объясняют как нормализовать whitespace в тегах и простых атрибутах, по сложным атрибутам отправляют к стандарту, по текстовым узлам между тегами вообще не говорят, тоже в стандарты надо лезть.

Отредактировано пользователем 11 сентября 2019 г. 7:35:46(UTC)  | Причина: Не указана

Offline oleg_kashin  
#25 Оставлено : 11 сентября 2019 г. 10:58:26(UTC)
oleg_kashin

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

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

Offline two_oceans  
#26 Оставлено : 11 сентября 2019 г. 14:34:54(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: oleg_kashin Перейти к цитате
Цитата:
А есть отдельно значения после трансформов, от которых хэш посчитан?

Есть - вот пример по "Пример 2012" для расчета 1 референса ...
То же самое с { PreserveWhitespace = true }...
Можете дать что идет на счет DigestValue 1 референса в Вашей программе по примеру "Пример 2012" и последний out.xml? - будут очень благодарен
Конечно могу, программа пишет логи и значения референсов в файлы. c решетками это референсы после трансформа, log1/log2 это лог подсчет хэша этих файлов референсов, signedinfo после трансформа и на всякий случай большой лог проверки.
refs.zip (27kb) загружен 5 раз(а).
С PreserveWhitespace = true в принципе похоже на выданное программкой.
Автор: oleg_kashin Перейти к цитате
В моем примере по out.xml получается одинаково до и после трансформа - нет комментариев
Зато есть отступы и переводы строк, так что строки могут отличаться.
Автор: oleg_kashin Перейти к цитате
Цитата:
К слову, когда я первый раз все отлаживал, то фиксировал guid и время, чтобы хэш всегда был одинаковый на время отладки
Всмысле тэг <xades:SigningTime> и id. По первому референсу давно не менял Id="a06356a7e8bd4239ad69b3e9c949bca1" - там стабильно должен идти один и тот же DigestValue
Да, время, и есть еще Id подписи от которого выходит xmldsig-...-signedprops..

Отредактировано пользователем 11 сентября 2019 г. 14:35:59(UTC)  | Причина: Не указана

Offline oleg_kashin  
#27 Оставлено : 12 сентября 2019 г. 13:39:10(UTC)
oleg_kashin

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

Группы: Участники
Зарегистрирован: 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) загружен 6 раз(а)., которую http://dss.cryptopro.ru/Verify/Verify/ пишет как подпись корректна, но ГИС ЖКХ опять та же ошибка формата подписи запроса.
может действительно как то по другому считать "DigestValue группы тэгов SigningCertificate" как писала поддержка ГИС ЖКХ - ощущение что уже хожу по кругу.

Отредактировано пользователем 12 сентября 2019 г. 16:08:56(UTC)  | Причина: чушь написал

Offline oleg_kashin  
#28 Оставлено : 12 сентября 2019 г. 14:10:39(UTC)
oleg_kashin

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

Группы: Участники
Зарегистрирован: 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.
Offline two_oceans  
#29 Оставлено : 16 сентября 2019 г. 5:59:47(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 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)  | Причина: Не указана

Offline Юрий Пичугин  
#30 Оставлено : 16 сентября 2019 г. 22:52:20(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) загружен 34 раз(а).

thanks 3 пользователей поблагодарили Юрий Пичугин за этот пост.
two_oceans оставлено 17.09.2019(UTC), oleg_kashin оставлено 18.09.2019(UTC), hunt-holding оставлено 24.01.2020(UTC)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
4 Страницы<1234>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.