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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline admin@uprio.ru  
#1 Оставлено : 8 июля 2020 г. 15:09:04(UTC)
admin@uprio.ru

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

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

Здравствуйте. Суть вопроса в следующем. Каким образом можно расшифровать элемент SignatureValue из XML запроса для СМЭВ имея открытую часть сертификата и само значение SignatureValue.
Sign.txt (1kb) загружен 6 раз(а).
Cert.txt (3kb) загружен 6 раз(а).
Online Андрей *  
#2 Оставлено : 8 июля 2020 г. 15:30:18(UTC)
Андрей *

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

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

Сказал «Спасибо»: 393 раз
Поблагодарили: 1612 раз в 1238 постах
Здравствуйте.

Это RAW-подпись.
Необходимо получить тот же XML (или файл), под которым вычислялся хеш.
Далее проверять подпись соответствующими языку программирования функциями.


На MS CryptoAPI это сценарий такой:
CryptAcquireContext(Prov... CRYPT_VERIFYCONTEXT)
CryptImportPublicKeyInfoEx (сертификат... &key)
CryptCreateHash(Prov...
CryptHashData(Hash, Memory, Size..)
CryptVerifySignature(Hash, Memory, Size, hKey..
Техническую поддержку оказываем тут
Наша база знаний
Offline admin@uprio.ru  
#3 Оставлено : 8 июля 2020 г. 15:41:20(UTC)
admin@uprio.ru

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

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

Автор: Андрей * Перейти к цитате
Здравствуйте.

Это RAW-подпись.
Необходимо получить тот же XML (или файл), под которым вычислялся хеш.
Далее проверять подпись соответствующими языку программирования функциями.


Это я знаю. Поэтому и спрашиваю как сделать следующее.

Вырезка из переписки с минсвязью.
Цитата:

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


Хочу разобраться, где я неправильно подписываю.
Online Андрей *  
#4 Оставлено : 8 июля 2020 г. 15:50:47(UTC)
Андрей *

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

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

Сказал «Спасибо»: 393 раз
Поблагодарили: 1612 раз в 1238 постах
Цитата:
канонизируется элемент SignedInfo с помощью алгоритма c14n

Думаю вот здесь проблема.
Пока будете по-разному "получать" - будет хеш другой, проверка не будет проходить.

Техническую поддержку оказываем тут
Наша база знаний
Online Андрей *  
#5 Оставлено : 8 июля 2020 г. 15:53:52(UTC)
Андрей *

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

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

Сказал «Спасибо»: 393 раз
Поблагодарили: 1612 раз в 1238 постах
Начните с самовалидации... примеры с корректной подписью от СМЭВ помогут - сделайте проверку подписи.
Как только будете проходить этот пункт - будет правильно и подписываться.
Техническую поддержку оказываем тут
Наша база знаний
Offline admin@uprio.ru  
#6 Оставлено : 8 июля 2020 г. 16:05:33(UTC)
admin@uprio.ru

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

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

У меня есть валидный запрос Zapros.xml (9kb) загружен 10 раз(а)., который проходит проверку.
Расчет HASH от узла BODY у меня получается такой же, как и в этом запросе (после канонизации). Непонятно с узлом SIGNEDINFO, ведь подписывается хэш от этого узла после канонизации. Вот я и хочу узнать хэш от signedinfo, чтобы понимать что я делаю не так. Или я что-то не до понимаю...
Offline two_oceans  
#7 Оставлено : 23 июля 2020 г. 6:14:27(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 319 раз в 300 постах
Добрый день. Я вернулся, так что можете по подписи XML адресовать вопросы мне - тоже долго бился со своей программой, теперь помогаю коллегам с этой бедой.
Автор: admin@uprio.ru Перейти к цитате
Вырезка из переписки с минсвязью.
Цитата:
...
- далее расшифровывается SignatureValue с помощью открытого ключа сертификата – x1;
- берется SignedInfo и считается от него хэш – x2, ...
Хочу разобраться, где я неправильно подписываю.
Эта цитата верна в случае зарубежных алгоритмов, однако применительно к гост и СМЭВ Вас того... обманули, короче. Поясняю:
SignatureValue для гост состоит из двух равных частей. Одна часть - проверочное значение получаемое после неких (описанных собственно в гост-2012) манипуляций с хэшем, закрытым ключом и случайным значением (проверочное значение берется за x1), вторая часть - само случайное значение (для вычисления x2). В отличие от шифрования которое теоретически можно обратить (расшифровать), в госте нет описания как обратить манипуляции гост-2012 и получить хэш. Зато есть описание как получить то же проверочное значение из хэша, открытого ключа и известного случайного значения. Поэтому при проверке подписи гост не восстанавливается значение хэша, а вычисляется проверочное значение с участием открытого ключа сертификата и именно оно берется за x2.

Это доставляет немало неудобств с отладкой подписи XML, так как приходится методом тыка подбирать от какого же преобразования текста сойдется хэш и подпись.
Offline admin@uprio.ru  
#8 Оставлено : 23 июля 2020 г. 12:26:31(UTC)
admin@uprio.ru

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

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

Автор: two_oceans Перейти к цитате
Добрый день. Я вернулся, так что можете по подписи XML адресовать вопросы мне - тоже долго бился со своей программой, теперь помогаю коллегам с этой бедой.

:) можете рассказать алгоритм действий?

Автор: two_oceans Перейти к цитате
Это доставляет немало неудобств с отладкой подписи XML, так как приходится методом тыка подбирать от какого же преобразования текста сойдется хэш и подпись.

т.е. хотите сказать, что надо смотреть в сторону каноникализации?

Offline two_oceans  
#9 Оставлено : 24 июля 2020 г. 5:03:50(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 319 раз в 300 постах
Автор: admin@uprio.ru Перейти к цитате
:) можете рассказать алгоритм действий?
Конечно, насколько подробно надо описать? В общих чертах вроде как правильно описали в ответе поддержки СМЭВ. Момент с которым которым обманули происходит внутри криптопровайдера (как "черный ящик" куда закинули открытый ключ, хэш SignedInfo и RAW значение подписи) и на самом деле любая программа, СМЭВ в том числе, получает от криптопровайдера только логический результат x1=x2 или x1!=x2.

Итак, подписание:

Проверка:
Добавлю, что не пугайтесь когда проверяете ответ СМЭВ и получаете результат ЭП-СМЭВ верна, ЭП-ОВ не верна, ЭП-СП верна. Это означает, что версия пространств имен у Вас и отвечающего разная и СМЭВ сделала медвежью услугу преобразовав ответ к Вашей версии и нарушила этим ЭП-ОВ. Для значимости ответа нужно восстановить версию отвечающего. Или сразу запрашивать по той же версии.
Автор: admin@uprio.ru Перейти к цитате
т.е. хотите сказать, что надо смотреть в сторону каноникализации?
Как правило да. Если вызываете штатные функции сертифицированного криптопровайдера и указываете правильно все алгоритмы (предопределенные константы должны быть с 2012 в названии), то с самим вычислением значения подписи и хэша проблем не должно быть. Остаются 3 важных момента:
1) соблюдать аккуратность и порядок действий чтобы не нарушить готовую верную подпись при вставке в документ. Например, если вырезали фрагмент из документа для каноникализации, важно перенести в него вышестоящие объявления пространств имен перед каноникализацией иначе каноническая форма вырезанного фрагмента будет отличаться от канонической формы этого же фрагмента в документе и при вставке подписи в документ получится неверная подпись. Штатные средства работы с XML должны это сделать автоматически, а вот если копируете документ как строку, то придется вручную добавлять. Если тег без префикса каноникализация даже не ругнется, что пространства имен нет.
2) каноникализация текста что подается в криптопровайдер (да, тут немало сюрпризов и мелких отличий от стандарта. В одной из тем экспериментами дошли до того что СМЭВ исключает символы с кодом 13 в значениях атрибутов даже в форме 
 коды 9 и 10 	 
 заменяются на пробел, при этом если получается несколько пробелов подряд они не заменяются на один пробел);
3) порядок байт значений из криптопровайдера (криптопровайдер криптопро возвращает в Little Endian, а стандарт требует Big Endian), тут надо оговориться что некоторые среды программирования и промежуточные программные "прокладки" уже учитывают это и переворачивать не надо. Однако другие не учитывают и приходится отзеркалить значение как массив байтов (первый байт меняется местами с последним, второй с предпоследним и т.д.)

Отредактировано пользователем 24 июля 2020 г. 5:04:55(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
Санчир Момолдаев оставлено 24.07.2020(UTC)
Offline admin@uprio.ru  
#10 Оставлено : 28 июля 2020 г. 16:52:45(UTC)
admin@uprio.ru

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

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

Спасибо за столь исчерпывающий ответ.
А можно "на пальцах"? У Вас получается сформировать подписанный запрос по ГОСТу 2012? Я пока не берусь делать проверку подписи, т.к. не могу корректно сформировать подпись. Хэш от элемента BODY я помещаю в DigestValue элемента SignedInfo, затем рассчитываю хэш от SignedInfo и подписываю его. Или я неправильно рассчитываю хэш, или неправильно подписываю.
Вот, что у меня получается Charge_20200728-2020-0000-0184-30544B43564A.zip (4kb) загружен 6 раз(а).
Offline two_oceans  
#11 Оставлено : 30 июля 2020 г. 6:59:25(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 319 раз в 300 постах
Фокус в том, что если есть верные подписанные файлы, то реализовать проверку и по ней калибровать подписание проще чем вслепую настраивать подписание. По крайней мере, я сначала делал проверку, так как был доступ к запросам в действующей региональной ИС. В смэв есть запросы, подписанные подписью, но без "чувствительных" данных. Особенно в СМЭВ 3 при работе с ГИС ГМП - там на 1 запрос с данными приходится куча подтверждений получения и частенько ответ "новых платежей нет". Если нужно для отладки проверки могу прислать такой запрос платежей и ответ, подписанные по гост-2012 (есть ответы гис гмп из тестовой смэв 2 и продуктивной смэв 3).

Вообще с файлом есть несколько нюансов: я предполагал в ответе что подписывается запрос в актуальную СМЭВ (СМЭВ 3), а тут запрос в формате СМЭВ 2. Предполагал СМЭВ 3, так как сервисы в СМЭВ 2 поэтапно закрывают, в том числе сервис ГИС ГМП, для которого пример файла первоначально обещали закрыть 1 ноября 2018 года, но уже несколько раз переносили, сейчас речь о 31 декабря 2020 года. От этого зависит местоположение подписи, способ указания сертификата, какое место документа подписано и какие трансформы. Кроме того, там еще есть заготовка второй подписи (подписи начисления). Содержимое начисления также странное в нескольких местах - пока опустим для ясности. Если это только для отладки подписания в уже рабочей системе - пойдет, но если только планируете работать в ГИС ГМП лучше подготовиться к СМЭВ 3.
Конкретно по проверочным пунктам (я не использую штатные функции XML, а собственный вариант вырезания фрагмента и каноникализации, поэтому есть еще несколько пунктов. Цитирую из лога, который определяется Блокнотом как win-1251, потому кириллица utf-8 в боди выглядит неверно): выделено значение подписи, успешно найден и выделен сертификат, выделен фрагмент
Код:
<ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"/><ds:Reference URI="#body"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/><ds:DigestValue>lDLx3a68Rc4Eb3yt4jap6tcW8jJNa9Z7ox+eXqJzSBc=</ds:DigestValue></ds:Reference></ds:SignedInfo>
для него выделены вышестоящие теги
Код:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:actor="http://smev.gosuslugi.ru/actors/smev"><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="ID_20200728-2020-0000-0184-30544B43564B-S"><ds:SignedInfo>
из вышестоящих тегов получен "контекст предков" для добавления понадобившихся в каноникализации пространств имен в сам фрагмент, применена нормализация переводов строк (в данном случае ничего не изменилось), применены решения о сохранении объявлений пространств имен в порядке закрытия тегов (первая строка TRY GET ANCESTOR NS о получении отсутствующего пространства имен для префикса ds из контекста предков, при этом оно сохранено PRESERVE в самом верхнем теге и удалено REMOVE из подчиненных).
в результате вышел каноничный текст
Код:
<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"></ds:SignatureMethod><ds:Reference URI="#body"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></ds:DigestMethod><ds:DigestValue>lDLx3a68Rc4Eb3yt4jap6tcW8jJNa9Z7ox+eXqJzSBc=</ds:DigestValue></ds:Reference></ds:SignedInfo>
Для него посчитан хэш гост-2012 прямым обращением к Microsoft CryptoApi, код алгоритма 32801, значение хэша (которое запрашивать не обязательно), перевернутое значение на всякий случай и перевернутое RAW значение подписи (в моем случае переворот значения подписи нужен):
Код:
0661 4C67 E416 27BE 5920 8612 E0B3 E356 16A8 7A69 365E 6E67 67A9 37D9 1017 2274
BmFMZ+QWJ75ZIIYS4LPjVhaoemk2Xm5nZ6k32RAXInQ=
7422 1710 D937 A967 676E 5E36 697A A816 56E3 B3E0 1286 2059 BE27 16E4 674C 6106
dCIXENk3qWdnbl42aXqoFlbjs+AShiBZvicW5GdMYQY=
5ED7 6207 BD8B 542C 96EE A285 F14C A242 256B CF2F 8963 C746 7C86 E636 60DE 3FB0 1C7B E104 8D86 A2D7 2192 8704 8DCF 3177 D744 EFA5 962E ADD0 4BA9 6437 8A40 6C99
XtdiB72LVCyW7qKF8UyiQiVrzy+JY8dGfIbmNmDeP7Ace+EEjYai1yGShwSNzzF310TvpZYurdBLqWQ3ikBsmQ==
Результат: значение не верно. Причина неизвестна - нужно знать канонический текст и значение хэша при подписании для выводов о причине.
Если канонический текст/хэш другой - дело в тексте/хэше, если текст и хэш те же, то дело или в перевороте значения или включен не тот сертификат.
Можно на этом заканчивать проверку, но для отладки продолжаю проверку референсов, фрагмент
Код:
<soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="body"><smev:GISGMPTransferMsg xmlns:smev="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/"><rev:Message xmlns:rev="http://smev.gosuslugi.ru/rev120315"><rev:Sender><rev:Code>RKZN01001</rev:Code><rev:Name>Казначейство России</rev:Name></rev:Sender><rev:Recipient><rev:Code>RKZN01001</rev:Code><rev:Name>Казначейство России</rev:Name></rev:Recipient><rev:ServiceName>GISGMP</rev:ServiceName><rev:TypeCode>GFNC</rev:TypeCode><rev:Status>REQUEST</rev:Status><rev:Date>2020-07-28T13:47:38</rev:Date><rev:ExchangeType>6</rev:ExchangeType></rev:Message><rev:MessageData xmlns:rev="http://smev.gosuslugi.ru/rev120315"><rev:AppData><gisgmp:RequestMessage xmlns:gisgmp="http://roskazna.ru/gisgmp/xsd/116/Message" xmlns:pdr="http://roskazna.ru/gisgmp/xsd/116/PGU_DataRequest" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" senderIdentifier="" senderRole="2" Id="ID_20200728-2020-0000-0184-30544B43564C" timestamp="2020-07-28T13:47:38"><msgd:ImportRequest xmlns:msgd="http://roskazna.ru/gisgmp/xsd/116/MessageData"><pir:Package xmlns:pir="http://roskazna.ru/gisgmp/xsd/116/PGU_ImportRequest"><pir:Document originatorID="001dc3"><chg:Charge xmlns:chg="http://roskazna.ru/gisgmp/xsd/116/Charge" Id="ID_20200728-2020-0000-0184-30544B43564B" supplierBillID="0000761920041500000001849" billDate="2020-04-15"><chg:ValidUntil>2020-05-15</chg:ValidUntil><chg:SupplierOrgInfo><org:Name xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">Управление имущественных отношений Брянской области</org:Name><org:INN xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">3250059309</org:INN><org:KPP xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">325701001</org:KPP><org:OGRN xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">1053244057085</org:OGRN><org:Account xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization"><org:AccountNumber>40101810300000010008</org:AccountNumber><org:Bank><org:Name>Отделение Брянск</org:Name><org:BIK>041501001</org:BIK></org:Bank></org:Account></chg:SupplierOrgInfo><chg:BillFor>safdsfgsdfgsdfg</chg:BillFor><chg:TotalAmount>15000</chg:TotalAmount><com:ChangeStatus xmlns:com="http://roskazna.ru/gisgmp/xsd/116/Common" meaning="1"/><chg:KBK>00000000000000000120</chg:KBK><chg:OKTMO>15701000</chg:OKTMO><chg:BudgetIndex><bdi:Status xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">13</bdi:Status><bdi:Purpose xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:Purpose><bdi:TaxPeriod xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">ГД.00.2020</bdi:TaxPeriod><bdi:TaxDocNumber xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:TaxDocNumber><bdi:TaxDocDate xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:TaxDocDate><bdi:PaymentType xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:PaymentType></chg:BudgetIndex><chg:AltPayerIdentifier>0100000000000000000000643</chg:AltPayerIdentifier><chg:PayerName>Селиванова Н В 0 г.р.</chg:PayerName><chg:TreasureBranch>УФК по Брянской области</chg:TreasureBranch><chg:LSvFO>04272004820</chg:LSvFO><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="ID_20200728-2020-0000-0184-30544B43564B-S"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/><ds:Reference URI="#ID_20200728-2020-0000-0184-30544B43564B"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue/></ds:Reference></ds:SignedInfo><ds:SignatureValue/><ds:KeyInfo><ds:X509Data><ds:X509Certificate></ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></chg:Charge></pir:Document></pir:Package></msgd:ImportRequest></gisgmp:RequestMessage></rev:AppData></rev:MessageData></smev:GISGMPTransferMsg></soapenv:Body>
вышестоящие до фрагмента
Код:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="body">
, решения пропущу, есть строка TRY GET ANCESTOR NS [soapenv] для недостающего пространства имен, результат
Код:
<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="body"><smev:GISGMPTransferMsg xmlns:smev="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/"><rev:Message xmlns:rev="http://smev.gosuslugi.ru/rev120315"><rev:Sender><rev:Code>RKZN01001</rev:Code><rev:Name>Казначейство России</rev:Name></rev:Sender><rev:Recipient><rev:Code>RKZN01001</rev:Code><rev:Name>Казначейство России</rev:Name></rev:Recipient><rev:ServiceName>GISGMP</rev:ServiceName><rev:TypeCode>GFNC</rev:TypeCode><rev:Status>REQUEST</rev:Status><rev:Date>2020-07-28T13:47:38</rev:Date><rev:ExchangeType>6</rev:ExchangeType></rev:Message><rev:MessageData xmlns:rev="http://smev.gosuslugi.ru/rev120315"><rev:AppData><gisgmp:RequestMessage xmlns:gisgmp="http://roskazna.ru/gisgmp/xsd/116/Message" Id="ID_20200728-2020-0000-0184-30544B43564C" senderIdentifier="" senderRole="2" timestamp="2020-07-28T13:47:38"><msgd:ImportRequest xmlns:msgd="http://roskazna.ru/gisgmp/xsd/116/MessageData"><pir:Package xmlns:pir="http://roskazna.ru/gisgmp/xsd/116/PGU_ImportRequest"><pir:Document originatorID="001dc3"><chg:Charge xmlns:chg="http://roskazna.ru/gisgmp/xsd/116/Charge" Id="ID_20200728-2020-0000-0184-30544B43564B" billDate="2020-04-15" supplierBillID="0000761920041500000001849"><chg:ValidUntil>2020-05-15</chg:ValidUntil><chg:SupplierOrgInfo><org:Name xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">Управление имущественных отношений Брянской области</org:Name><org:INN xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">3250059309</org:INN><org:KPP xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">325701001</org:KPP><org:OGRN xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">1053244057085</org:OGRN><org:Account xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization"><org:AccountNumber>40101810300000010008</org:AccountNumber><org:Bank><org:Name>Отделение Брянск</org:Name><org:BIK>041501001</org:BIK></org:Bank></org:Account></chg:SupplierOrgInfo><chg:BillFor>safdsfgsdfgsdfg</chg:BillFor><chg:TotalAmount>15000</chg:TotalAmount><com:ChangeStatus xmlns:com="http://roskazna.ru/gisgmp/xsd/116/Common" meaning="1"></com:ChangeStatus><chg:KBK>00000000000000000120</chg:KBK><chg:OKTMO>15701000</chg:OKTMO><chg:BudgetIndex><bdi:Status xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">13</bdi:Status><bdi:Purpose xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:Purpose><bdi:TaxPeriod xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">ГД.00.2020</bdi:TaxPeriod><bdi:TaxDocNumber xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:TaxDocNumber><bdi:TaxDocDate xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:TaxDocDate><bdi:PaymentType xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:PaymentType></chg:BudgetIndex><chg:AltPayerIdentifier>0100000000000000000000643</chg:AltPayerIdentifier><chg:PayerName>Селиванова Н В 0 г.р.</chg:PayerName><chg:TreasureBranch>УФК по Брянской области</chg:TreasureBranch><chg:LSvFO>04272004820</chg:LSvFO><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="ID_20200728-2020-0000-0184-30544B43564B-S"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"></ds:SignatureMethod><ds:Reference URI="#ID_20200728-2020-0000-0184-30544B43564B"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"></ds:DigestMethod><ds:DigestValue></ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue></ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate></ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></chg:Charge></pir:Document></pir:Package></msgd:ImportRequest></gisgmp:RequestMessage></rev:AppData></rev:MessageData></smev:GISGMPTransferMsg></soapenv:Body>
Хэш гост-2012 от него и перевернутый хэш
Код:
DE61 26EC 366E 0D50 D073 D08A 84FB B40C 67F1 EFF4 F984 5FE3 28DD B7C7 6D90 5D14
3mEm7DZuDVDQc9CKhPu0DGfx7/T5hF/jKN23x22QXRQ=
FF2Qbce33SjjX4T59O/xZwy0+4SK0HPQUA1uNuwmYd4=
значение DigestValue: lDLx3a68Rc4Eb3yt4jap6tcW8jJNa9Z7ox+eXqJzSBc=, вывод хэш первого референса не совпадает (причем дело в каноничном тексте, а не в перевороте значения), больше референсов нет, подпись не верна.

Для второй подписи соответственно каноничный текст референса:
Код:
<chg:Charge xmlns:chg="http://roskazna.ru/gisgmp/xsd/116/Charge" Id="ID_20200728-2020-0000-0184-30544B43564B" billDate="2020-04-15" supplierBillID="0000761920041500000001849"><chg:ValidUntil>2020-05-15</chg:ValidUntil><chg:SupplierOrgInfo><org:Name xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">Управление имущественных отношений Брянской области</org:Name><org:INN xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">3250059309</org:INN><org:KPP xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">325701001</org:KPP><org:OGRN xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization">1053244057085</org:OGRN><org:Account xmlns:org="http://roskazna.ru/gisgmp/xsd/116/Organization"><org:AccountNumber>40101810300000010008</org:AccountNumber><org:Bank><org:Name>Отделение Брянск</org:Name><org:BIK>041501001</org:BIK></org:Bank></org:Account></chg:SupplierOrgInfo><chg:BillFor>safdsfgsdfgsdfg</chg:BillFor><chg:TotalAmount>15000</chg:TotalAmount><com:ChangeStatus xmlns:com="http://roskazna.ru/gisgmp/xsd/116/Common" meaning="1"></com:ChangeStatus><chg:KBK>00000000000000000120</chg:KBK><chg:OKTMO>15701000</chg:OKTMO><chg:BudgetIndex><bdi:Status xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">13</bdi:Status><bdi:Purpose xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:Purpose><bdi:TaxPeriod xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">ГД.00.2020</bdi:TaxPeriod><bdi:TaxDocNumber xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:TaxDocNumber><bdi:TaxDocDate xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:TaxDocDate><bdi:PaymentType xmlns:bdi="http://roskazna.ru/gisgmp/xsd/116/BudgetIndex">0</bdi:PaymentType></chg:BudgetIndex><chg:AltPayerIdentifier>0100000000000000000000643</chg:AltPayerIdentifier><chg:PayerName>Селиванова Н В 0 г.р.</chg:PayerName><chg:TreasureBranch>УФК по Брянской области</chg:TreasureBranch><chg:LSvFO>04272004820</chg:LSvFO></chg:Charge>
хэш гост-94 как указано во второй подписи должен быть wwB127yMeVEcAVXbaW+8HSxVWFlQLRdQciU3oA8v8Us=, хэш гост-2012 wzvCC/QpsMFl3f0usHQfOU/NOYn2gqiNSCFfIg1O1+4=

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

Offline avialaynen  
#12 Оставлено : 21 сентября 2021 г. 9:09:54(UTC)
avialaynen

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

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

Автор: two_oceans Перейти к цитате
Добавлю, что не пугайтесь когда проверяете ответ СМЭВ и получаете результат ЭП-СМЭВ верна, ЭП-ОВ не верна, ЭП-СП верна. Это означает, что версия пространств имен у Вас и отвечающего разная и СМЭВ сделала медвежью услугу преобразовав ответ к Вашей версии и нарушила этим ЭП-ОВ. Для значимости ответа нужно восстановить версию отвечающего. Или сразу запрашивать по той же версии.

А можно поподробней?
Зачем СМЭВ это делает? Как с этим бороться? Как запросить у СМЭВа, что именно он поменял? Учитывая, что техподдержка СМЭВа отвечает стандартными отписками "ЭП-ОВ не верна, проверяйте сами у себя, что вы не так делаете".

Upd. В моём случае неймспейсы оказались вовсе не причём, у меня джавовская служба перед отправкой xml в СМЭВ задавала не ту кодировку, из-за чего вся кириллица превращалась в знаки вопроса, и СМЭВ проверял не тот текст, что я (как я думал) отправлял.

Отредактировано пользователем 22 сентября 2021 г. 12:50:34(UTC)  | Причина: Не указана

Offline two_oceans  
#13 Оставлено : 24 сентября 2021 г. 8:31:09(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 319 раз в 300 постах
Автор: avialaynen Перейти к цитате
Автор: two_oceans Перейти к цитате
Добавлю, что не пугайтесь когда проверяете ответ СМЭВ и получаете результат ЭП-СМЭВ верна, ЭП-ОВ не верна, ЭП-СП верна. Это означает, что версия пространств имен у Вас и отвечающего разная и СМЭВ сделала медвежью услугу преобразовав ответ к Вашей версии и нарушила этим ЭП-ОВ. Для значимости ответа нужно восстановить версию отвечающего. Или сразу запрашивать по той же версии.
А можно поподробней?
Зачем СМЭВ это делает?
Такая "фишка" называется "мультиверсионность". Это про ответ другого участника СМЭВ. Суть в том, что у видов сведений (ВС), запущенных до принятия версии 3.50 не регламентировано какая версия единого сервиса СМЭВ3 должна использоваться (по словам техподдержки). Обращаться можно по любой версии, у версий разные адреса, так что ответ СМЭВ 3 очевидно будет по той версии на адрес которой обратились. И тут начитается подстава - в адресах пространств имен указывается номер версии. При возврате ответа СМЭВ вырезает кусочек с ответом посланным другим участником СМЭВ (как текст, то есть специально не учитывает что номер версии другой) и его подписью (как фрагмент).

С одной стороны, это хорошо - допустим, реализовано у Вас составление запросов к версии 1.1 единого сервиса СМЭВ, а другая сторона принимает запросы от единого сервиса СМЭВ версии 1.2 и Вы можете общаться. С другой стороны, общение будет с искажениями. СМЭВ проверит, что ЭП-ОВ верна на Вашей версии и пропустит запрос. Другая сторона получит Вашу ЭП-ОВ (нарушенную) и ЭП-СМЭВ (верную) на своей версии. Соответственно СМЭВ проверит ЭП-ОВ ответа на версии другой стороны, а Вам выдаст ЭП-ОВ (нарушенную) и ЭП-СМЭВ (верную) на Вашей версии сервиса. ЭП-СМЭВ как бы подтверждает, что ЭП-ОВ была верная на момент приема от другой стороны. В спецификации правда указано, что ЭП-ОВ не должна прилагаться после такого преобразования, проверять следует ЭП-СМЭВ, но по факту сломанная ЭП-ОВ тоже приходит.

ЭП-СП не нарушается, так как не использует спорных пространств имен. ЭП-СМЭВ верная, потому что накладывается после искажения. Заметьте, что есть цифру версии в адресе пространства имен поставить на версию другой стороны, то ЭП-ОВ должна стать верна, но ЭП-СМЭВ будет неверна.

Касательно версий, на версии 1.1 есть кажется запрос статуса очередей, который заменили в новейшей версии на push сервис. Поэтому если push у Вас не сделан, то можно держать версию 1.1 для такого опроса, ну а сами запросы отправлять по более новым версиям.
Автор: avialaynen Перейти к цитате
Как с этим бороться? Как запросить у СМЭВа, что именно он поменял?
Запросить никак. В идеале нужно знать к какой версии СМЭВ обращается другая сторона и использовать ее же. Подсказкой могут служить "лишние" неиспользуемые пространства имен "вытесненные" к вырезанной из оригинального документа Signature. Добиться ответа всегда ли они туда вытесняются не удалось - техподдержка так и не поняла чего я от них спрашиваю. На вопрос "как узнать версию на другой стороне?" порекомендовали звонить по номерам, указанным в списке ответственных того ведомства.
Автор: avialaynen Перейти к цитате
Учитывая, что техподдержка СМЭВа отвечает стандартными отписками "ЭП-ОВ не верна, проверяйте сами у себя, что вы не так делаете".
Это про ответ СМЭВ на Ваш запрос. Тут действительно сложно что-то определенное сказать, так как СМЭВ еще не посчитала ЭП-ОВ верной, то есть испортить еще было нечего.
Цитата:
Upd. В моём случае неймспейсы оказались вовсе не причём, у меня джавовская служба перед отправкой xml в СМЭВ задавала не ту кодировку, из-за чего вся кириллица превращалась в знаки вопроса, и СМЭВ проверял не тот текст, что я (как я думал) отправлял.
С кириллицей частенько такое, выручает utf-8.

Отредактировано пользователем 27 сентября 2021 г. 8:08:16(UTC)  | Причина: Не указана

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