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

Уведомление

Icon
Error

3 Страницы<123>
Опции
К последнему сообщению К первому непрочитанному
Offline Dartwed1989  
#11 Оставлено : 24 мая 2019 г. 16:00:39(UTC)
Dartwed1989

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

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

Поблагодарили: 1 раз в 1 постах
XW7BDREV10S045760_Registracija_Zapros.xml (30kb) загружен 26 раз(а).


Обновил подпись файла согласно Вашим комментариям. Добавил строку сверху и включаю в расчет хеша тег SenderInformayionSystemSignature. Кроме этого убрал все проблемы в структуре подписи. Файл приложил.
Можно ли узнать на каком этапе проверки подписи возникает ошибка?
Offline two_oceans  
#12 Оставлено : 27 мая 2019 г. 7:21:22(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: Dartwed1989 Перейти к цитате
По "правильному" файлу можно ли определить данные в каких тегах подписываются?
По "правильному" файлу в референсе также указывается URI="" и enveloped-signature, то есть подписывается весь нормализованный документ за исключением Signature и вложенных в Signature тегов. Тем не менее алгоритм каноникализации в референсе отсутствует, что вызывает неоднозначность обработки.

Нормализованный - это значит, что все последовательности символов 13 затем 10 (переводы строк Windows) заменяются на одиночный символ 10, одиночные символы 13 (переводы строк Mac) заменяются на одиночные 10, то есть все переводы строк будут только 10. Если перед тегом Signature и сразу после него есть "текстовые узлы" (включая "whitespace" - табуляцию или переводы строк, пробелы), текстовые узлы остаются в тексте передаваемом на обработку.

Далее алгоритм каноникализации обрабатывает и удаляет теги начинающиеся с вопросительного знака - инструкции обработки и xml декларацию, заменяет последовательности начинающиеся со знаков амперсанда и процента. Комментарии могут оставаться или исключаться (меняется урн метода в документе). Кодировка приводится к UTF-8. При эксклюзивной нормализации тем не менее можно указать параметр InclusiveNamespaces со списком префиксов пространств имен, к которым применится неэксклюзивный вариант (под тегом CanonicalizationMethod или Transform добавляется тег InclusiveNamespaces, адрес пространства имен равно идентификатору эксклюзивной каноникализации). Параметр PreserveWhitespace позволяет подобрать вариант обработки пробелов и табуляций - оптимизировать или оставить как есть, это параметр вроде бы не отражается в тексте документа, приходится подбирать.

У меня по умолчанию при отсутствии каноникализации стояло применение C14N (неэксклюзивного варианта). Отключил неэксклюзивный вариант, получилось вообще без преобразований после исключения подписи - хэш "правильного" файла не сходится. Попробую изменить на эксключивный вариант.

С новым вариантом XW7BDREV10S045760_Registracija_Zapros.xml - тоже самое, теперь SignedInfo без переводов строк и значение SignatureValue прошло проверку, но с хэшем пока что-то не то.

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

Offline Dartwed1989  
#13 Оставлено : 27 мая 2019 г. 17:35:40(UTC)
Dartwed1989

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

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

Поблагодарили: 1 раз в 1 постах
Я думаю, проблема в том, что встроенная компонента 1С, которой я пользуюсь некорректно каноникализирует строку XML из-за того что передается неправильный путь xPath.

Я описывал в первом сообщении, что подписываю одну строку xml, а хэш и подпись вставляю в другую. Делал я так только потому, что мне не удалось сформировать путь XPATH, который бы исключал теги подписи при каноникализации строки с данными. В типовом варианте работы этой процедуры используется одна строка xml, содержащая все данные и теги подписи. Встроенная компонента 1С, которая каноникализирует xml работает по принципу черного ящика. Знаю лишь, что используется C14N(). На вход подается строка xml и тег xpath для получения каноникализированного текста.

В итоге я решил доработать типовую процедуру для работы с двумя xml файлами - в одном все данные, кроме тегов подписи(но включая теги SenderInformationSystemSignature), в другой строке те же данные + теги подписи Sygnature. В итоге Хэш все равно неправильный.

Мне кажется, что надо вернуться к типовому виду данной процедуры 1С, но правильно передать на вход путь XPATH для подписываемых данных. К сожалению, такой путь сформировать у меня не получается.




Offline two_oceans  
#14 Оставлено : 28 мая 2019 г. 5:29:15(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
К сожалению, в построении XPath я не силен. Скорее всего для целого документа должно быть что-то простое вроде //* Каноникализация по идее и не должна выкидывать Signature, это функция другого трансформа, применяемого перед каноникализацией. С другой стороны, если реализация позволяет, почему бы не совместить. Возможно надо добавить условие xpath на отрицание
Код:
ancestor-or-self::dsig:Signature
(это выборка Signature и его потомков, благо тег Signature один и можно не осторожничать). В одном из прошлых сообщений в этой теме я процитировал текст стандарта про трансформу enveloped-signature вместе с эквивалентным выражением xpath, возможно оно подойдет как есть.

На что я вчера обратил еще внимание - строку для подписи Вы прислали не нормализованную (с переводами строк Windows), а итоговый документ получился уже нормализованный (слипается в блокноте в одну строку, значит переводы строк только из символов с кодом 10). То есть посчитали хэш от строки с символами с кодом 13 (каноникализация их не удаляет, а заменяет на строку
Код:
&#xD;
), а потом отправляете итог без символов 13 (нормализация их меняет на 10). Еще момент в том, что после каноникализации у Вас символы 13 остались, то есть замена символов 13 похоже вообще не реализована в 1С (потому что их не должно быть в нормализованном тексте xml). По идее программа проверки хэша никак не узнает, что надо еще символы 13 примешать перед каноникализацией и да еще не заменять их и хэш получится другой. Другими словами, перед подачей строки для подписи Вам нужно либо строку для подписи загрузить во второй объект xml (такой же как тот, в котором собираете итоговый конверт, так как при загрузке строки обычно выполняется нормализация) и выгрузить обратно (также как формируте итоговый документ) либо вручную провести замены в строке для подписи chr(13) & chr(10) на chr(10), потом chr(13) на chr(10).

К сожалению, моя реализация эксклюзивной каноникализации явно неправильно работает на "правильном" файле: на входе 244560 байт, после enveloped трансформа 240868 байт, после нормализации 240453 байт, после каноникализации 911 байт (много тегов вообще выкинуто).

С другой стороны, на Вашем варианте более ожидаемый результат: вход 30540 байт (второй Ваш файл), после enveloped трансформа 26001 байт (значит тег Signature 4539 байт), после нормализации 26001 байт (уже нормализована), после каноникализации 35904 байт (увеличивается за счет объявлений пространств имен). Хотя как минимум вижу одну ошибку в своем результате с тегом RequestMessage (из-за того, что он без префикса и пустой префикс не объявлен, это скорее всего не соответствие схеме, хотя в "правильном файле" также) и моя реализация добавляет объявление xmlns="", которое не нужно если выше еще нигде не было xmlns=. Попробую сравнить свой каноникализированный вариант первого файла с Вашим и с эталоном (программка на .NET 4.5), может быть еще отличия найдутся.

Отредактировано пользователем 28 мая 2019 г. 5:47:13(UTC)  | Причина: Не указана

Offline Dartwed1989  
#15 Оставлено : 29 мая 2019 г. 16:21:05(UTC)
Dartwed1989

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

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

Поблагодарили: 1 раз в 1 постах
KonvertSOAPItogV1S.txt (29kb) загружен 24 раз(а). KonvertSOAPItogVSEhP.xml (30kb) загружен 18 раз(а). KonvertSOAP.txt (28kb) загружен 35 раз(а). KonvertSOAPKanonikalizacija.txt (37kb) загружен 37 раз(а).
Добрый день!

Я немного переделал программу. Теперь получается следующее:

1. Получаю строку xml с данными и с тегами подписи(см. КонвертSOAP). Я просто скопировал строку, которая получается в программе в текстовый файл и приложил к сообщению.
2. Каноникализация данной строки. У меня получилось составить XPath таким образом, чтобы тег Signature не учитывался. Получилось следующее - см. КонвертSOAPКаноникализация. К сожалению, компонента 1С, которая производит каноникализацию строки выдает ошибку, если в строке XML есть <?xml version="1.0" encoding="UTF-8" standalone="no"?>. Поэтому каноникализирую без этой строки. Затем просто добавляю ее в начало итоговой строки. Запросил у 1С почему так, жду ответ. Пробовал не добавлять, подпись все равно в итоге не верна.
3. После каноникализации рассчитывается хэш и подпись и вставляется в эту же строку xml. Приложил файл КонвертSOAPИтогВ1С - это то, что у меня получается непосредственно в программе, до сохранения в файл xml. И сам итоговый файл xml, который передаю в Систему электронных паспортов.

Перед каноникализацией сохраняю строку в xml файл с форматом UTF-8, затем дополнительно убираю символы с кодом 13 если они есть.
Offline two_oceans  
#16 Оставлено : 30 мая 2019 г. 8:34:09(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
1. После беглого просмотра - во всех файлах txt присутствуют символы с кодом 13, в итоговом не присутствуют. То есть что-то кардинально меняется в xml. Символы 13 должны быть убраны до каноникализации, но раз каноникализация их игнорит, то хотя бы до вычисления хэша.

Тут конечно возможен вариант с сохранением файла копированием при котором добавляются символы, попробуйте не копировать, а сохранить из 1С. Кстати, насколько помню 1С хранит строки в win-1251 или даже в ascii (866), что не очень подходит для работы с подписанием xml. Чтобы перевести в UTF-8, желательно вывести текст в текстовый объект ADODB.Stream с кодировкой UTF-8, потом сохранить в файл (или перечитать строку из стрима). На VBScript выглядит примерно так (адаптируйте на русские названия методов/свойств под 1С, где-то тут уже была тема с адаптированным кодом):
Код:
Set ShtStream = CreateObject("ADODB.Stream")
    ShtStream.Mode = 3 'разрешение на чтение и запись
    ShtStream.Type = 2 'тип данных - 1 Binary 2 Text
    ShtStream.Charset = "UTF-8"
    ShtStream.Open
    ShtStream.WriteText S
    ShtStream.SaveToFile FN
    ShtStream.Close
    Set ShtStream = Nothing

Методом WriteText не вставляется переводов строк. FN имя файла, S выаодимый в файл текст.
Правда там тоже есть хитрость, в начало файла добавляется метка порядка байтов (3 байта для utf-8), которая должна быть выкинута при расчете хэша, поэтому сохраненный в тестовом режиме файл надо перечитать в двоичном типе данных ADODB.Stream с позиции 3 и сохранить снова, если идет на вычисление хэша.

2. Если добавлена строка <?xml с указанием кодировки UTF-8, то и фактическая кодировка переданного текста должна быть UTF-8. То есть если Вы подаете с этой строкой, но в другой кодировке - каноникализация закономерно выдаст ошибку (в utf-8 должна быть определенная последовательность байт, например, два символа кириллицы подряд в кодировке win-1251 вызовут ошибку при декодировании utf-8), скорее всего дело в этом, но могут быть еще нюансы специфичные для 1С. Перед каноникализацией и вычислением хэша нужно убедиться что фактическая кодировка текста utf-8.

3. Общий подход к программе звучит верно.

Отредактировано пользователем 30 мая 2019 г. 8:36:12(UTC)  | Причина: Не указана

Offline Dartwed1989  
#17 Оставлено : 31 мая 2019 г. 10:32:01(UTC)
Dartwed1989

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

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

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

Вчера у меня получилось подписать пустой файл. При этом я заметил некую странность работы компоненты 1С при каноникализации строки.

Подписываю xml строку следующего формата:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><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=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></ds:Transforms><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/><ds:DigestValue>%DigestValue%</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>%SignatureValue%</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>%BinarySecurityToken%</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

Подпись вставляю в тег Header.

Каноникализация в 1С:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header></soapenv:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>

Данная каноническая форма xml соответствует форме, которую я получаю на другом онлайн ресурсе.
В результате, сервис https://www.justsign.me/verifyqca/Verify/ возвращает сообщение, что подпись математически корректна. При этом в коде 1С я воспользовался объектом ADODB.Stream и убрал метки порядка байтов. Правда позже выяснил, что при сохранении xml строки в файл формата utf-8 в 1с можно передавать параметр, который определяет наличие этих байтов. В общем, с нормализацией строки разобрался.
Кроме того, добавление строки "<?xml version="1.0" encoding="UTF-8" standalone="no"?>" в начало xml файла после подписи, никак не повлияло на конечный результат. Подпись корректна.

Однако.
Если попробовать подписать похожую пустую xml строку:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><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=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></ds:Transforms><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/><ds:DigestValue>%DigestValue%</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>%SignatureValue%</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>%BinarySecurityToken%</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

В данной строке добавлено объявление пространства имен xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

Каноническая форма в 1С:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header></soapenv:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>

Каноническая форма на стороннем ресурсе:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header></soapenv:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>

Я заметил, что объявление пространства имен xmlns:xsi в канонической форме остается, а в 1С убирается.
В итоге подпись на ресурсе не проходит. Может быть проблема исключительно в этом? В файлах примерах, что я присылал ранее, пространства имен в канонической форме также убраны, а на стороннем ресурсе они остаются(перепроверил). Я не придал этому значения тогда.
К сожалению, мне пока не удалось на ресурсах 1С найти описание работы процедуры C14N() встроенной компоненты, запросил у тех поддержки описание, но пока ответа нет.
Посмотрел описание процедуры в гугле, но не понял, можно ли передавать какой-либо параметр на вход, чтобы на выходе не убирались пространства имен.


Offline two_oceans  
#18 Оставлено : 31 мая 2019 г. 13:28:10(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: Dartwed1989 Перейти к цитате
Добрый день!
Вчера у меня получилось подписать пустой файл.
... добавление строки "<?xml version="1.0" encoding="UTF-8" standalone="no"?>" в начало xml файла после подписи, никак не повлияло на конечный результат. Подпись корректна.
Тут все понятно, рад что наметился прогресс. У этого примера как я понимаю одинаковые эксклюзивная и неэксклюзивная канонические формы.
Автор: Dartwed1989 Перейти к цитате
Однако. Если попробовать подписать похожую пустую xml строку:
...
В данной строке добавлено объявление пространства имен xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

Каноническая форма в 1С:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header></soapenv:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>

Каноническая форма на стороннем ресурсе:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header></soapenv:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>
Я заметил, что объявление пространства имен xmlns:xsi в канонической форме остается, а в 1С убирается.
Ну вообще я наверно на стороне 1С - неиспользуемое пространство имен должно быть выкинуто при эксклюзивной каноникализации (при неэксклюзивной вроде бы может и остаться). То есть тут есть отличие между каноническими формами и я (уже наверно в третий раз) предлагаю явно задать метод каноникализации дополнительным трансформом под референсом, после enveloped-signature. Хотя отдельный вызов каноникализации все равно его не обработает, но можно узнать какая все же у Вас форма и заставить другую сторону использовать такую же при проверке подписи. Для ясности: какую форму выбираете на стороннем сайте? Наверно можно наглядно прояснить это если взять такой пример:
Код:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Header xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:Signature/></soapenv:Header>
	<soapenv:Body></soapenv:Body>
</soapenv:Envelope>
Эксклюзивная форма перенесет объявление xmlns:ds вниз, а неэксклюзивная вверх. Если 1С и сторонний ресурс перенесут в разные стороны, то у них разные формы каноникализации.

Другой вопрос, если Вы добавите любой атрибут или тег с префиксом xsi тогда пространство будет использовано и оставлено в любой форме. В "правильном" файле эту нагрузку "удержания xsi" несет атрибут xsi:schemaLocation, однако мне кажется странным этот параметр использовать не в схеме, честно я бы выкинул и параметр и объявление xsi.
Автор: Dartwed1989 Перейти к цитате
Посмотрел описание процедуры в гугле, но не понял, можно ли передавать какой-либо параметр на вход, чтобы на выходе не убирались пространства имен.
Если нет атрибута или тега из пространства имен xsi, то можно было бы теоретически передать в эксклюзивную каноникализацию параметр InclusiveNamespaces со значением xsi, тогда скорее всего алгоритм его не выкинет. Как передать его в 1С остается вопросом, но параметр является частью стандарта.

Собственно, просто выкидыванием пространства xsi все равно не решить проблему, так как у Вас возможно то же самое будет с пространством ds, если поднимите его объявление на уровень выше как в "правильном" файле.

Отредактировано пользователем 31 мая 2019 г. 13:38:39(UTC)  | Причина: Не указана

Offline Dartwed1989  
#19 Оставлено : 3 июня 2019 г. 10:57:42(UTC)
Dartwed1989

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

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

Поблагодарили: 1 раз в 1 постах
XW7BDREV10S045760_Registracija_Zapros.xml (30kb) загружен 59 раз(а).
Добрый день!

У меня получилось настроить электронную подпись. Прикладываю файл, по которому сервис проверки подписи показал, что подпись корректна. Да и всистеме электронных паспортов не было ошибки по подписи.

Я указал в файле напрямую метод каноникализации(если я правильно все понял, то указан эксклюзивный вариант, по которому работает каноникализация в 1С) + не добавляю байты порядка файлов при сохранении в файл из 1С, и как следствие все работает.

Огромное спасибо за помощь!
Offline ZMikhail  
#20 Оставлено : 10 июня 2019 г. 20:39:34(UTC)
ZMikhail

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

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

Добрый день!
Столкнулся сейчас с точно такой же проблемой!
Подскажите, пжлст, каким образом удалось исключить элемент "Signature" в запросе XPath?
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
3 Страницы<123>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.